<!DOCTYPE html>
<html lang="en"><head>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
   <title>HTTP Extensions for Distributed Authoring -- WEBDAV</title><script type="application/javascript">
function getMeta(rfcno, container) {

  var xhr = new XMLHttpRequest();
  xhr.open("GET", "https://tools.ietf.org/draft/rfc" + rfcno + "/state.xml", true);
  xhr.onload = function (e) {
    if (xhr.readyState === 4) {
      if (xhr.status === 200) {
        var doc = xhr.responseXML;
        var info = getChildByName(doc.documentElement, "info");
  
        var cont = document.getElementById(container);
        // empty the container
        while (cont.firstChild) {
          cont.removeChild(myNode.firstChild);
        }      
  
        var c = getChildByName(info, "stdstatus");
        if (c !== null) {
          var bld = newElementWithText("b", c.textContent);
          cont.appendChild(bld);
        }
  
        c = getChildByName(info, "updatedby");
        if (c !== null) {
          cont.appendChild(newElement("br"));
          cont.appendChild(newText("Updated by: "));
          appendRfcLinks(cont, c.textContent);
        }
  
        c = getChildByName(info, "obsoletedby");
        if (c !== null) {
          cont.appendChild(newElement("br"));
          cont.appendChild(newText("Obsoleted by: "));
          appendRfcLinks(cont, c.textContent);
        }
        
        c = getChildByName(info, "errata");
        if (c !== null) {
          cont.appendChild(newElement("br"));
          var link = newElementWithText("a", "errata");
          link.setAttribute("href", "http://www.rfc-editor.org/errata_search.php?rfc=" + rfcno);
          var errata = newElementWithText("i", "This document has ");
          errata.appendChild(link);
          errata.appendChild(newText("."));
          cont.appendChild(errata);
        }

        cont.style.display = "block";
      } else {
        console.error(xhr.statusText);
      }
    }
  };
  xhr.onerror = function (e) {
    console.error(xhr.status + " " + xhr.statusText);
  };
  xhr.send(null);
}

// DOM helpers
function newElement(name) {
  return document.createElement(name);
}
function newElementWithText(name, txt) {
  var e = document.createElement(name);
  e.appendChild(newText(txt));
  return e;
}
function newText(text) {
  return document.createTextNode(text);
}

function getChildByName(parent, name) {
  if (parent === null) {
    return null;
  }
  else {
    for (var c = parent.firstChild; c !== null; c = c.nextSibling) {
      if (name == c.nodeName) {
        return c;
      }
    }
    return null;
  }
}

function appendRfcLinks(parent, text) {
  var updates = text.split(",");
  for (var i = 0; i < updates.length; i++) {
    var rfc = updates[i].trim();
    if (rfc.substring(0, 3) == "rfc") {
      var link = newElement("a");
      link.setAttribute("href", "http://tools.ietf.org/html/" + rfc);
      link.appendChild(newText(rfc.substring(3)));
      parent.appendChild(link);
    } else {
      parent.appendChild(newText(rfc));
    }
    if (i != updates.length - 1) {
      parent.appendChild(newText(", "));
    }
  }
}
</script><script type="application/javascript">
function anchorRewrite() {
  map = { "activelock": "ELEMENT_activelock", "depth": "ELEMENT_depth", "locktoken": "ELEMENT_locktoken", "timeout": "ELEMENT_timeout", "collection": "ELEMENT_collection", "href": "ELEMENT_href", "link": "ELEMENT_link", "dst": "ELEMENT_dst", "src": "ELEMENT_src", "lockentry": "ELEMENT_lockentry", "lockinfo": "ELEMENT_lockinfo", "lockscope": "ELEMENT_lockscope", "exclusive": "ELEMENT_exclusive", "shared": "ELEMENT_shared", "locktype": "ELEMENT_locktype", "write": "ELEMENT_write", "multistatus": "ELEMENT_multistatus", "response": "ELEMENT_response", "propstat": "ELEMENT_propstat", "status": "ELEMENT_status", "responsedescription": "ELEMENT_responsedescription", "owner": "ELEMENT_owner", "prop": "ELEMENT_prop", "propertybehavior": "ELEMENT_propertybehaviour", "keepalive": "ELEMENT_keepalive", "omit": "ELEMENT_omit", "propertyupdate": "ELEMENT_propertyupdate", "remove": "ELEMENT_remove", "set": "ELEMENT_set", "propfind": "ELEMENT_propfind", "allprop": "ELEMENT_allprop", "propname": "ELEMENT_propname", "creationdate": "PROPERTY_creationdate", "displayname": "PROPERTY_displayname", "getcontentlanguage": "PROPERTY_getcontentlanguage", "getcontentlength": "PROPERTY_getcontentlength", "getcontenttype": "PROPERTY_getcontenttype", "getetag": "PROPERTY_getetag", "getlastmodified": "PROPERTY_getlastmodified", "lockdiscovery": "PROPERTY_lockdiscovery", "resourcetype": "PROPERTY_resourcetype", "source": "PROPERTY_source", "supportedlock": "PROPERTY_supportedlock"};
  if (window.location.hash.length >= 1) {
    var fragid = window.location.hash.substr(1);
    if (fragid) {
      if (! document.getElementById(fragid)) {
        var prefix = "rfc.";
        var mapped = map[fragid];
        if (mapped) {
          window.location.hash = mapped;
        } else if (fragid.indexOf("section-") == 0) {
          window.location.hash = prefix + "section." + fragid.substring(8);
        } else if (fragid.indexOf("appendix-") == 0) {
          window.location.hash = prefix + "section." + fragid.substring(9);
        } else if (fragid.indexOf("s-") == 0) {
          window.location.hash = prefix + "section." + fragid.substring(2);
        } else if (fragid.indexOf("p-") == 0) {
          var r = fragid.substring(2);
          var p = r.indexOf("-");
          if (p >= 0) {
            window.location.hash = prefix + "section." + r.substring(0, p) + ".p." + r.substring(p + 1);
          }
        }
      }
    }  
  }
}
window.addEventListener('hashchange', anchorRewrite);
window.addEventListener('DOMContentLoaded', anchorRewrite);
</script><style type="text/css" title="Xml2Rfc (sans serif)">
a {
  text-decoration: none;
}
a.smpl {
  color: black;
}
a:hover {
  text-decoration: underline;
}
a:active {
  text-decoration: underline;
}
address {
  margin-top: 1em;
  margin-left: 2em;
  font-style: normal;
}
body {
  color: black;
  font-family: cambria, georgia, serif;
  font-size: 12pt;
  margin: 2em auto;
  max-width: 1000px;
}
samp, span.tt, code, pre {
  font-family: consolas, monaco, monospace;
}
cite {
  font-style: normal;
}
dl {
  margin-left: 2em;
}
dl > dt {
  float: left;
  margin-right: 1em;
}
dl.nohang > dt {
  float: none;
}
dl > dd {
  margin-bottom: .5em;
}
dl.compact > dd {
  margin-bottom: .0em;
}
dl > dd > dl {
  margin-top: 0.5em;
}
ul.empty {
  list-style-type: none;
}
ul.empty li {
  margin-top: .5em;
}
dl p {
  margin-left: 0em;
}
dl.reference > dt {
  font-weight: bold;
}
dl.reference > dd {
  margin-left: 6em;
}
h1 {
  color: green;
  font-size: 150%;
  line-height: 18pt;
  font-weight: bold;
  text-align: center;
  margin-top: 36pt;
  margin-bottom: 0pt;
}
h2 {
  font-size: 130%;
  line-height: 21pt;
  page-break-after: avoid;
}
h2.np {
  page-break-before: always;
}
h3 {
  font-size: 120%;
  line-height: 15pt;
  page-break-after: avoid;
}
h4 {
  font-size: 110%;
  page-break-after: avoid;
}
h5, h6 {
  page-break-after: avoid;
}
h1 a, h2 a, h3 a, h4 a, h5 a, h6 a {
  color: black;
}
img {
  margin-left: 3em;
}
li {
  margin-left: 2em;
}
ol {
  margin-left: 2em;
}
ol.la {
  list-style-type: lower-alpha;
}
ol.ua {
  list-style-type: upper-alpha;
}
ol p {
  margin-left: 0em;
}
p {
  margin-left: 2em;
}
pre {
  font-size: 11pt;
  margin-left: 3em;
  background-color: lightyellow;
  padding: .25em;
  page-break-inside: avoid;
}
pre.text2 {
  border-style: dotted;
  border-width: 1px;
  background-color: #f0f0f0;
}
pre.inline {
  background-color: white;
  padding: 0em;
  page-break-inside: auto;
}
pre.text {
  border-style: dotted;
  border-width: 1px;
  background-color: #f8f8f8;
}
pre.drawing {
  border-style: solid;
  border-width: 1px;
  background-color: #f8f8f8;
  padding: 2em;
}
table {
  margin-left: 2em;
}
div.tt {
  margin-left: 2em;
} 
table.tt {
  border-collapse: collapse;
  border-color: gray;
  border-spacing: 0; 
  vertical-align: top;
 }
table.tt th {
  border-color: gray;
  padding: 3px;
}
table.tt td {
  border-color: gray;
  padding: 3px;
}
table.all {
  border-style: solid;
  border-width: 2px;
}
table.full {
  border-style: solid;
  border-width: 2px;
}
table.tt td {
  vertical-align: top;
}
table.all td {
  border-style: solid;
  border-width: 1px;
}
table.full td {
  border-style: none solid;
  border-width: 1px;
}
table.tt th {
  vertical-align: top;
}
table.all th {
  border-style: solid;
  border-width: 1px;
}
table.full th {
  border-style: solid;
  border-width: 1px 1px 2px 1px;
}
table.headers th {
  border-style: none none solid none;
  border-width: 2px;
}
table.tleft {
  margin-right: auto;
}
table.tright {
  margin-left: auto;
}
table.tcenter {
  margin-left: auto;
  margin-right: auto;
}
caption {
  caption-side: bottom;
  font-weight: bold;
  font-size: 10pt;
  margin-top: .5em;
}

table.header {
  border-spacing: 1px;
  width: 95%;
  font-size: 11pt;
  color: white;
}
td.top {
  vertical-align: top;
}
td.topnowrap {
  vertical-align: top;
  white-space: nowrap;
}
table.header td {
  background-color: gray;
  width: 50%;
}
ul.toc, ul.toc ul {
  list-style: none;
  margin-left: 1.5em;
  padding-left: 0em;
}
ul.toc li {
  line-height: 150%;
  font-weight: bold;
  margin-left: 0em;
}
ul.toc li li {
  line-height: normal;
  font-weight: normal;
  font-size: 11pt;
  margin-left: 0em;
}
li.excluded {
  font-size: 0pt;
}
ul p {
  margin-left: 0em;
}
.filename, h1, h2, h3, h4 {
  font-family: candara, calibri, segoe, optima, arial, sans-serif;
}
ul.ind, ul.ind ul {
  list-style: none;
  margin-left: 1.5em;
  padding-left: 0em;
  page-break-before: avoid;
}
ul.ind li {
  font-weight: bold;
  line-height: 200%;
  margin-left: 0em;
}
ul.ind li li {
  font-weight: normal;
  line-height: 150%;
  margin-left: 0em;
}
.avoidbreakinside {
  page-break-inside: avoid;
}
.avoidbreakafter {
  page-break-after: avoid;
}
.bcp14 {
  font-style: normal;
  text-transform: lowercase;
  font-variant: small-caps;
}
.comment {
  background-color: yellow;
}
.center {
  text-align: center;
}
.error {
  color: red;
  font-style: italic;
  font-weight: bold;
}
.figure {
  font-weight: bold;
  text-align: center;
  font-size: 10pt;
}
.filename {
  color: #333333;
  font-size: 112%;
  font-weight: bold;
  line-height: 21pt;
  text-align: center;
  margin-top: 0pt;
}
.fn {
  font-weight: bold;
}
.left {
  text-align: left;
}
.right {
  text-align: right;
}
.warning {
  font-size: 130%;
  background-color: yellow;
}
.self {
    color: #999999;
    margin-left: .3em;
    text-decoration: none;
    visibility: hidden;
    -webkit-user-select: none; 
    -moz-user-select: none;
    -ms-user-select: none;
}
.self:hover {
    text-decoration: none;
}
p:hover .self {
    visibility: visible;
}
.docstatus {
  border: 1px solid black;
  display: none;
  float: right;
  margin: 2em;
  padding: 1em;
}

@media screen {
  pre.text, pre.text2 {
    width: 69em;
  }
}

@media print {
  .noprint {
    display: none;
  }

  a {
    color: black;
    text-decoration: none;
  }

  table.header {
    width: 90%;
  }

  td.header {
    width: 50%;
    color: black;
    background-color: white;
    vertical-align: top;
    font-size: 110%;
  }

  ul.toc a:last-child::after {
    content: leader('.') target-counter(attr(href), page);
  }

  ul.ind li li a {
    content: target-counter(attr(href), page);
  }

  pre {
    font-size: 10pt;
  }

  .print2col {
    column-count: 2;
    -moz-column-count: 2;
    column-fill: auto;
  }
}
@page {
  @top-left {
       content: "RFC 2518";
  }
  @top-right {
       content: "February 1999";
  }
  @top-center {
       content: "WEBDAV";
  }
  @bottom-left {
       content: "Goland, et al.";
  }
  @bottom-center {
       content: "Standards Track";
  }
  @bottom-right {
       content: "[Page " counter(page) "]";
  }
}
@page:first {
    @top-left {
      content: normal;
    }
    @top-right {
      content: normal;
    }
    @top-center {
      content: normal;
    }
}
</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyright"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Notational Conventions" href="#rfc.section.2"><link rel="Chapter" title="3 Terminology" href="#rfc.section.3"><link rel="Chapter" title="4 Data Model for Resource Properties" href="#rfc.section.4"><link rel="Chapter" title="5 Collections of Web Resources" href="#rfc.section.5"><link rel="Chapter" title="6 Locking" href="#rfc.section.6"><link rel="Chapter" title="7 Write Lock" href="#rfc.section.7"><link rel="Chapter" title="8 HTTP Methods for Distributed Authoring" href="#rfc.section.8"><link rel="Chapter" title="9 HTTP Headers for Distributed Authoring" href="#rfc.section.9"><link rel="Chapter" title="10 Status Code Extensions to HTTP/1.1" href="#rfc.section.10"><link rel="Chapter" title="11 Multi-Status Response" href="#rfc.section.11"><link rel="Chapter" title="12 XML Element Definitions" href="#rfc.section.12"><link rel="Chapter" title="13 DAV Properties" href="#rfc.section.13"><link rel="Chapter" title="14 Instructions for Processing XML in DAV" href="#rfc.section.14"><link rel="Chapter" title="15 DAV Compliance Classes" href="#rfc.section.15"><link rel="Chapter" title="16 Internationalization Considerations" href="#rfc.section.16"><link rel="Chapter" title="17 Security Considerations" href="#rfc.section.17"><link rel="Chapter" title="18 IANA Considerations" href="#rfc.section.18"><link rel="Chapter" title="19 Intellectual Property" href="#rfc.section.19"><link rel="Chapter" title="20 Acknowledgements" href="#rfc.section.20"><link rel="Chapter" href="#rfc.section.21" title="21 References"><link rel="Appendix" title="23 Appendices" href="#rfc.section.23"><link rel="Alternate" title="Authoritative ASCII Version" href="http://www.ietf.org/rfc/rfc2518.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc2518"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc2518"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.840, 2016/11/16 05:32:10, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><link rel="schema.dcterms" href="http://purl.org/dc/terms/"><meta name="dcterms.creator" content="Goland, Y."><meta name="dcterms.creator" content="Whitehead, E."><meta name="dcterms.creator" content="Faizi, A."><meta name="dcterms.creator" content="Carter, S.R."><meta name="dcterms.creator" content="Jensen, D."><meta name="dcterms.identifier" content="urn:ietf:rfc:2518"><meta name="dcterms.issued" content="1999-02"><meta name="dcterms.abstract" content="This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance)."><meta name="dcterms.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance)."></head><body onload='getMeta(2518,"rfc.meta");'><header><table class="header" id="rfc.headerblock"><tbody><tr><td class="left">Network Working Group</td><td class="right">Y. Goland</td></tr><tr><td class="left">Request for Comments: 2518</td><td class="right">Microsoft</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">E. Whitehead</td></tr><tr><td class="left"></td><td class="right">UC Irvine</td></tr><tr><td class="left"></td><td class="right">A. Faizi</td></tr><tr><td class="left"></td><td class="right">Netscape</td></tr><tr><td class="left"></td><td class="right">S. Carter</td></tr><tr><td class="left"></td><td class="right">D. Jensen</td></tr><tr><td class="left"></td><td class="right">Novell</td></tr><tr><td class="left"></td><td class="right">February 1999</td></tr></tbody></table><div id="rfc.title"><h1>HTTP Extensions for Distributed Authoring -- WEBDAV</h1></div></header><div id="rfc.meta" class="docstatus" style="display: block;"><b>PROPOSED STANDARD</b><br>Obsoleted by: <a href="http://tools.ietf.org/html/rfc4918">4918</a><br><i>This document has <a href="http://www.rfc-editor.org/errata_search.php?rfc=2518">errata</a>.</i></div><section id="rfc.status"><h2><a href="#rfc.status">Status of this Memo</a></h2><p>This
 document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 
improvements. Please refer to the current edition of the “Internet 
Official Protocol Standards” (STD 1) for the standardization state and 
status of this protocol. Distribution of this memo is unlimited.</p></section><section id="rfc.copyrightnotice"><h2><a href="#rfc.copyrightnotice">Copyright Notice</a></h2><p>Copyright © The Internet Society (1999). All Rights Reserved.</p></section><section id="rfc.abstract"><h2><a href="#rfc.abstract">Abstract</a></h2><p>This
 document specifies a set of methods, headers, and content-types 
ancillary to HTTP/1.1 for the management of resource properties, 
creation and management of resource collections, namespace manipulation,
 and resource locking (collision avoidance).</p></section><hr class="noprint"><nav id="rfc.toc"><h2 class="np"><a href="#rfc.toc">Table of Contents</a></h2><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1">Introduction</a></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2">Notational Conventions</a></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3">Terminology</a></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#data.model.for.resource.properties">Data Model for Resource Properties</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.1">The Resource Property Model</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.2">Existing Metadata Proposals</a></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.3">Properties and HTTP Headers</a></li><li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.4">Property Values</a></li><li><a href="#rfc.section.4.5">4.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.5">Property Names</a></li><li><a href="#rfc.section.4.6">4.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.6">Media Independent Links</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#collections.of.web.resources">Collections of Web Resources</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#http.url.namespace.model">HTTP URL Namespace Model</a></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#collection.resources">Collection Resources</a></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.3">Creation and Retrieval of Collection Resources</a></li><li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.4">Source Resources and Output Resources</a></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#locking">Locking</a><ul><li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.1">Exclusive Vs. Shared Locks</a></li><li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.2">Required Support</a></li><li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.3">Lock Tokens</a></li><li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#opaquelocktoken.lock.token.uri.scheme">opaquelocktoken Lock Token URI Scheme</a><ul><li><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#node.field.generation.without.the.ieee.802.address">Node Field Generation Without the IEEE 802 Address</a></li></ul></li><li><a href="#rfc.section.6.5">6.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.5">Lock Capability Discovery</a></li><li><a href="#rfc.section.6.6">6.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.6">Active Lock Discovery</a></li><li><a href="#rfc.section.6.7">6.7</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.7">Usage Considerations</a></li></ul></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7">Write Lock</a><ul><li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.1">Methods Restricted by Write Locks</a></li><li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.2">Write Locks and Lock Tokens</a></li><li><a href="#rfc.section.7.3">7.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.3">Write Locks and Properties</a></li><li><a href="#rfc.section.7.4">7.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.4">Write Locks and Null Resources</a></li><li><a href="#rfc.section.7.5">7.5</a>&nbsp;&nbsp;&nbsp;<a href="#write.locks.and.collections">Write Locks and Collections</a></li><li><a href="#rfc.section.7.6">7.6</a>&nbsp;&nbsp;&nbsp;<a href="#write.locks.and.the.if.request.header">Write Locks and the If Request Header</a><ul><li><a href="#rfc.section.7.6.1">7.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.6.1">Example - Write Lock</a></li></ul></li><li><a href="#rfc.section.7.7">7.7</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.7">Write Locks and COPY/MOVE</a></li><li><a href="#rfc.section.7.8">7.8</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.8">Refreshing Write Locks</a></li></ul></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#http.methods.for.distributed.authoring">HTTP Methods for Distributed Authoring</a><ul><li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_PROPFIND">PROPFIND</a><ul><li><a href="#rfc.section.8.1.1">8.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.1.1">Example - Retrieving Named Properties</a></li><li><a href="#rfc.section.8.1.2">8.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.1.2">Example - Using allprop to Retrieve All Properties</a></li><li><a href="#rfc.section.8.1.3">8.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.1.3">Example - Using propname to Retrieve all Property Names</a></li></ul></li><li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_PROPPATCH">PROPPATCH</a><ul><li><a href="#rfc.section.8.2.1">8.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.2.1">Status Codes for use with 207 (Multi-Status)</a></li><li><a href="#rfc.section.8.2.2">8.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.2.2">Example - PROPPATCH</a></li></ul></li><li><a href="#rfc.section.8.3">8.3</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_MKCOL">MKCOL Method</a><ul><li><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.3.1">Request</a></li><li><a href="#rfc.section.8.3.2">8.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.3.2">Status Codes</a></li><li><a href="#rfc.section.8.3.3">8.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.3.3">Example - MKCOL</a></li></ul></li><li><a href="#rfc.section.8.4">8.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.4">GET, HEAD for Collections</a></li><li><a href="#rfc.section.8.5">8.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.5">POST for Collections</a></li><li><a href="#rfc.section.8.6">8.6</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_DELETE">DELETE</a><ul><li><a href="#rfc.section.8.6.1">8.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.6.1">DELETE for Non-Collection Resources</a></li><li><a href="#rfc.section.8.6.2">8.6.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.6.2">DELETE for Collections</a></li></ul></li><li><a href="#rfc.section.8.7">8.7</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_PUT">PUT</a><ul><li><a href="#rfc.section.8.7.1">8.7.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.7.1">PUT for Non-Collection Resources</a></li><li><a href="#rfc.section.8.7.2">8.7.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.7.2">PUT for Collections</a></li></ul></li><li><a href="#rfc.section.8.8">8.8</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_COPY">COPY Method</a><ul><li><a href="#rfc.section.8.8.1">8.8.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.8.1">COPY for HTTP/1.1 resources</a></li><li><a href="#rfc.section.8.8.2">8.8.2</a>&nbsp;&nbsp;&nbsp;<a href="#copy.for.properties">COPY for Properties</a></li><li><a href="#rfc.section.8.8.3">8.8.3</a>&nbsp;&nbsp;&nbsp;<a href="#copy.for.collections">COPY for Collections</a></li><li><a href="#rfc.section.8.8.4">8.8.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.8.4">COPY and the Overwrite Header</a></li><li><a href="#rfc.section.8.8.5">8.8.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.8.5">Status Codes</a></li><li><a href="#rfc.section.8.8.6">8.8.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.8.6">Example - COPY with Overwrite</a></li><li><a href="#rfc.section.8.8.7">8.8.7</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.8.7">Example - COPY with No Overwrite</a></li><li><a href="#rfc.section.8.8.8">8.8.8</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.8.8">Example - COPY of a Collection</a></li></ul></li><li><a href="#rfc.section.8.9">8.9</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_MOVE">MOVE Method</a><ul><li><a href="#rfc.section.8.9.1">8.9.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.9.1">MOVE for Properties</a></li><li><a href="#rfc.section.8.9.2">8.9.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.9.2">MOVE for Collections</a></li><li><a href="#rfc.section.8.9.3">8.9.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.9.3">MOVE and the Overwrite Header</a></li><li><a href="#rfc.section.8.9.4">8.9.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.9.4">Status Codes</a></li><li><a href="#rfc.section.8.9.5">8.9.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.9.5">Example - MOVE of a Non-Collection</a></li><li><a href="#rfc.section.8.9.6">8.9.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.9.6">Example - MOVE of a Collection</a></li></ul></li><li><a href="#rfc.section.8.10">8.10</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_LOCK">LOCK Method</a><ul><li><a href="#rfc.section.8.10.1">8.10.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.1">Operation</a></li><li><a href="#rfc.section.8.10.2">8.10.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.2">The Effect of Locks on Properties and Collections</a></li><li><a href="#rfc.section.8.10.3">8.10.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.3">Locking Replicated Resources</a></li><li><a href="#rfc.section.8.10.4">8.10.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.4">Depth and Locking</a></li><li><a href="#rfc.section.8.10.5">8.10.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.5">Interaction with other Methods</a></li><li><a href="#rfc.section.8.10.6">8.10.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.6">Lock Compatibility Table</a></li><li><a href="#rfc.section.8.10.7">8.10.7</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.7">Status Codes</a></li><li><a href="#rfc.section.8.10.8">8.10.8</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.8">Example - Simple Lock Request</a></li><li><a href="#rfc.section.8.10.9">8.10.9</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.9">Example - Refreshing a Write Lock</a></li><li><a href="#rfc.section.8.10.10">8.10.10</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.10">Example - Multi-Resource Lock Request</a></li></ul></li><li><a href="#rfc.section.8.11">8.11</a>&nbsp;&nbsp;&nbsp;<a href="#METHOD_UNLOCK">UNLOCK Method</a><ul><li><a href="#rfc.section.8.11.1">8.11.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.11.1">Example - UNLOCK</a></li></ul></li></ul></li><li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#http.headers.for.distributed.authoring">HTTP Headers for Distributed Authoring</a><ul><li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#HEADER_DAV">DAV Header</a></li><li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#HEADER_Depth">Depth Header</a></li><li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#HEADER_Destination">Destination Header</a></li><li><a href="#rfc.section.9.4">9.4</a>&nbsp;&nbsp;&nbsp;<a href="#HEADER_If">If Header</a><ul><li><a href="#rfc.section.9.4.1">9.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.4.1">No-tag-list Production</a></li><li><a href="#rfc.section.9.4.2">9.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.4.2">Tagged-list Production</a></li><li><a href="#rfc.section.9.4.3">9.4.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.4.3">not Production</a></li><li><a href="#rfc.section.9.4.4">9.4.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.4.4">Matching Function</a></li><li><a href="#rfc.section.9.4.5">9.4.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.4.5">If Header and Non-DAV Compliant Proxies</a></li></ul></li><li><a href="#rfc.section.9.5">9.5</a>&nbsp;&nbsp;&nbsp;<a href="#HEADER_Lock-Token">Lock-Token Header</a></li><li><a href="#rfc.section.9.6">9.6</a>&nbsp;&nbsp;&nbsp;<a href="#HEADER_Overwrite">Overwrite Header</a></li><li><a href="#rfc.section.9.7">9.7</a>&nbsp;&nbsp;&nbsp;<a href="#HEADER_Status-URI">Status-URI Response Header</a></li><li><a href="#rfc.section.9.8">9.8</a>&nbsp;&nbsp;&nbsp;<a href="#HEADER_Timeout">Timeout Request Header</a></li></ul></li><li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.extensions.to.http11">Status Code Extensions to HTTP/1.1</a><ul><li><a href="#rfc.section.10.1">10.1</a>&nbsp;&nbsp;&nbsp;<a href="#STATUS_102">102 Processing</a></li><li><a href="#rfc.section.10.2">10.2</a>&nbsp;&nbsp;&nbsp;<a href="#STATUS_207">207 Multi-Status</a></li><li><a href="#rfc.section.10.3">10.3</a>&nbsp;&nbsp;&nbsp;<a href="#STATUS_422">422 Unprocessable Entity</a></li><li><a href="#rfc.section.10.4">10.4</a>&nbsp;&nbsp;&nbsp;<a href="#STATUS_423">423 Locked</a></li><li><a href="#rfc.section.10.5">10.5</a>&nbsp;&nbsp;&nbsp;<a href="#STATUS_424">424 Failed Dependency</a></li><li><a href="#rfc.section.10.6">10.6</a>&nbsp;&nbsp;&nbsp;<a href="#STATUS_507">507 Insufficient Storage</a></li></ul></li><li><a href="#rfc.section.11">11.</a>&nbsp;&nbsp;&nbsp;<a href="#multi-status.response">Multi-Status Response</a></li><li><a href="#rfc.section.12">12.</a>&nbsp;&nbsp;&nbsp;<a href="#xml.element.definitions">XML Element Definitions</a><ul><li><a href="#rfc.section.12.1">12.1</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_activelock">activelock XML Element</a><ul><li><a href="#rfc.section.12.1.1">12.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_depth">depth XML Element</a></li><li><a href="#rfc.section.12.1.2">12.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_locktoken">locktoken XML Element</a></li><li><a href="#rfc.section.12.1.3">12.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_timeout">timeout XML Element</a></li></ul></li><li><a href="#rfc.section.12.2">12.2</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_collection">collection XML Element</a></li><li><a href="#rfc.section.12.3">12.3</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_href">href XML Element</a></li><li><a href="#rfc.section.12.4">12.4</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_link">link XML Element</a><ul><li><a href="#rfc.section.12.4.1">12.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_dst">dst XML Element</a></li><li><a href="#rfc.section.12.4.2">12.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_src">src XML Element</a></li></ul></li><li><a href="#rfc.section.12.5">12.5</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_lockentry">lockentry XML Element</a></li><li><a href="#rfc.section.12.6">12.6</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_lockinfo">lockinfo XML Element</a></li><li><a href="#rfc.section.12.7">12.7</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_lockscope">lockscope XML Element</a><ul><li><a href="#rfc.section.12.7.1">12.7.1</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_exclusive">exclusive XML Element</a></li><li><a href="#rfc.section.12.7.2">12.7.2</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_shared">shared XML Element</a></li></ul></li><li><a href="#rfc.section.12.8">12.8</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_locktype">locktype XML Element</a><ul><li><a href="#rfc.section.12.8.1">12.8.1</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_write">write XML Element</a></li></ul></li><li><a href="#rfc.section.12.9">12.9</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_multistatus">multistatus XML Element</a><ul><li><a href="#rfc.section.12.9.1">12.9.1</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_response">response XML Element</a></li><li><a href="#rfc.section.12.9.2">12.9.2</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_responsedescription">responsedescription XML Element</a></li></ul></li><li><a href="#rfc.section.12.10">12.10</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_owner">owner XML Element</a></li><li><a href="#rfc.section.12.11">12.11</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_prop">prop XML element</a></li><li><a href="#rfc.section.12.12">12.12</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_propertybehaviour">propertybehavior XML element</a><ul><li><a href="#rfc.section.12.12.1">12.12.1</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_keepalive">keepalive XML element</a></li><li><a href="#rfc.section.12.12.2">12.12.2</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_omit">omit XML element</a></li></ul></li><li><a href="#rfc.section.12.13">12.13</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_propertyupdate">propertyupdate XML element</a><ul><li><a href="#rfc.section.12.13.1">12.13.1</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_remove">remove XML element</a></li><li><a href="#rfc.section.12.13.2">12.13.2</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_set">set XML element</a></li></ul></li><li><a href="#rfc.section.12.14">12.14</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_propfind">propfind XML Element</a><ul><li><a href="#rfc.section.12.14.1">12.14.1</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_allprop">allprop XML Element</a></li><li><a href="#rfc.section.12.14.2">12.14.2</a>&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_propname">propname XML Element</a></li></ul></li></ul></li><li><a href="#rfc.section.13">13.</a>&nbsp;&nbsp;&nbsp;<a href="#dav.properties">DAV Properties</a><ul><li><a href="#rfc.section.13.1">13.1</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_creationdate">creationdate Property</a></li><li><a href="#rfc.section.13.2">13.2</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_displayname">displayname Property</a></li><li><a href="#rfc.section.13.3">13.3</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_getcontentlanguage">getcontentlanguage Property</a></li><li><a href="#rfc.section.13.4">13.4</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_getcontentlength">getcontentlength Property</a></li><li><a href="#rfc.section.13.5">13.5</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_getcontenttype">getcontenttype Property</a></li><li><a href="#rfc.section.13.6">13.6</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_getetag">getetag Property</a></li><li><a href="#rfc.section.13.7">13.7</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_getlastmodified">getlastmodified Property</a></li><li><a href="#rfc.section.13.8">13.8</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_lockdiscovery">lockdiscovery Property</a><ul><li><a href="#rfc.section.13.8.1">13.8.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.13.8.1">Example - Retrieving the lockdiscovery Property</a></li></ul></li><li><a href="#rfc.section.13.9">13.9</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_resourcetype">resourcetype Property</a></li><li><a href="#rfc.section.13.10">13.10</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_source">source Property</a><ul><li><a href="#rfc.section.13.10.1">13.10.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.13.10.1">Example - A source Property</a></li></ul></li><li><a href="#rfc.section.13.11">13.11</a>&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_supportedlock">supportedlock Property</a><ul><li><a href="#rfc.section.13.11.1">13.11.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.13.11.1">Example - Retrieving the supportedlock Property</a></li></ul></li></ul></li><li><a href="#rfc.section.14">14.</a>&nbsp;&nbsp;&nbsp;<a href="#instructions.for.processing.xml.in.dav">Instructions for Processing XML in DAV</a></li><li><a href="#rfc.section.15">15.</a>&nbsp;&nbsp;&nbsp;<a href="#dav.compliance.classes">DAV Compliance Classes</a><ul><li><a href="#rfc.section.15.1">15.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.15.1">Class 1</a></li><li><a href="#rfc.section.15.2">15.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.15.2">Class 2</a></li></ul></li><li><a href="#rfc.section.16">16.</a>&nbsp;&nbsp;&nbsp;<a href="#internationalization.considerations">Internationalization Considerations</a></li><li><a href="#rfc.section.17">17.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul><li><a href="#rfc.section.17.1">17.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.17.1">Authentication of Clients</a></li><li><a href="#rfc.section.17.2">17.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.17.2">Denial of Service</a></li><li><a href="#rfc.section.17.3">17.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.17.3">Security through Obscurity</a></li><li><a href="#rfc.section.17.4">17.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.17.4">Privacy Issues Connected to Locks</a></li><li><a href="#rfc.section.17.5">17.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.17.5">Privacy Issues Connected to Properties</a></li><li><a href="#rfc.section.17.6">17.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.17.6">Reduction of Security due to Source Link</a></li><li><a href="#rfc.section.17.7">17.7</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.17.7">Implications of XML External Entities</a></li><li><a href="#rfc.section.17.8">17.8</a>&nbsp;&nbsp;&nbsp;<a href="#risks.connected.with.lock.tokens">Risks Connected with Lock Tokens</a></li></ul></li><li><a href="#rfc.section.18">18.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.18">IANA Considerations</a></li><li><a href="#rfc.section.19">19.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.19">Intellectual Property</a></li><li><a href="#rfc.section.20">20.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.20">Acknowledgements</a></li><li><a href="#rfc.section.21">21.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.21.1">21.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.21.2">21.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informational References</a></li></ul></li><li><a href="#rfc.section.22">22.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.authors">Authors' Addresses</a></li><li><a href="#rfc.section.23">23.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.23">Appendices</a><ul><li><a href="#rfc.section.23.1">23.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.23.1">Appendix 1 - WebDAV Document Type Definition</a></li><li><a href="#rfc.section.23.2">23.2</a>&nbsp;&nbsp;&nbsp;<a href="#iso.8601.date.and.time.profile">Appendix 2 - ISO 8601 Date and Time Profile</a></li><li><a href="#rfc.section.23.3">23.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.23.3">Appendix 3 - Notes on Processing XML Elements</a><ul><li><a href="#rfc.section.23.3.1">23.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.23.3.1">Notes on Empty XML Elements</a></li><li><a href="#rfc.section.23.3.2">23.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.23.3.2">Notes on Illegal XML Processing</a></li></ul></li><li><a href="#rfc.section.23.4">23.4</a>&nbsp;&nbsp;&nbsp;<a href="#xml.namespaces.for.webdav">Appendix 4 -- XML Namespaces for WebDAV</a><ul><li><a href="#rfc.section.23.4.1">23.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.23.4.1">Introduction</a></li><li><a href="#rfc.section.23.4.2">23.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.23.4.2">Meaning of Qualified Names</a></li></ul></li></ul></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li></ul></nav><section id="n-introduction_1"><h2 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#n-introduction_1">Introduction</a></h2><div id="rfc.section.1.p.1" class="avoidbreakafter"><p>This
 document describes an extension to the HTTP/1.1 protocol that allows 
clients to perform remote web content authoring operations. This 
extension provides a coherent set of methods, headers, request entity 
body formats, and response entity body formats that provide operations 
for:<a class="self" href="#rfc.section.1.p.1">¶</a></p></div><div id="rfc.section.1.p.2"><p>Properties:
 The ability to create, remove, and query information about Web pages, 
such as their authors, creation dates, etc. Also, the ability to link 
pages of any media type to related pages.<a class="self" href="#rfc.section.1.p.2">¶</a></p></div><div id="rfc.section.1.p.3"><p>Collections:
 The ability to create sets of documents and to retrieve a hierarchical 
membership listing (like a directory listing in a file system).<a class="self" href="#rfc.section.1.p.3">¶</a></p></div><div id="rfc.section.1.p.4"><p>Locking:
 The ability to keep more than one person from working on a document at 
the same time. This prevents the "lost update problem," in which 
modifications are lost as first one author then another writes changes 
without merging the other author's changes.<a class="self" href="#rfc.section.1.p.4">¶</a></p></div><div id="rfc.section.1.p.5"><p>Namespace Operations: The ability to instruct the server to copy and move Web resources.<a class="self" href="#rfc.section.1.p.5">¶</a></p></div><div id="rfc.section.1.p.6"><p>Requirements
 and rationale for these operations are described in a companion 
document, "Requirements for a Distributed Authoring and Versioning 
Protocol for the World Wide Web" <a href="#RFC2291" id="rfc.xref.RFC2291.1"><cite title="Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web">[RFC2291]</cite></a>.<a class="self" href="#rfc.section.1.p.6">¶</a></p></div><div id="rfc.section.1.p.7"><p>The sections below provide a detailed introduction to resource properties (<a href="#data.model.for.resource.properties" title="Data Model for Resource Properties">Section&nbsp;4</a>), collections of resources (<a href="#collections.of.web.resources" title="Collections of Web Resources">Section&nbsp;5</a>), and locking operations (<a href="#locking" title="Locking">Section&nbsp;6</a>). These sections introduce the abstractions manipulated by the WebDAV-specific HTTP methods described in <a href="#http.methods.for.distributed.authoring" title="HTTP Methods for Distributed Authoring">Section&nbsp;8</a>, "HTTP Methods for Distributed Authoring".<a class="self" href="#rfc.section.1.p.7">¶</a></p></div><div id="rfc.section.1.p.8"><p>In
 HTTP/1.1, method parameter information was exclusively encoded in HTTP 
headers. Unlike HTTP/1.1, WebDAV encodes method parameter information 
either in an Extensible Markup Language (XML) <a href="#REC-XML" id="rfc.xref.REC-XML.1"><cite title="Extensible Markup Language (XML) 1.0">[REC-XML]</cite></a>
 request entity body, or in an HTTP header. The use of XML to encode 
method parameters was motivated by the ability to add extra XML elements
 to existing structures, providing extensibility; and by XML's ability 
to encode information in ISO 10646 character sets, providing 
internationalization support. As a rule of thumb, parameters are encoded
 in XML entity bodies when they have unbounded length, or when they may 
be shown to a human user and hence require encoding in an ISO 10646 
character set. Otherwise, parameters are encoded within HTTP headers. <a href="#http.headers.for.distributed.authoring" title="HTTP Headers for Distributed Authoring">Section&nbsp;9</a> describes the new HTTP headers used with WebDAV methods.<a class="self" href="#rfc.section.1.p.8">¶</a></p></div><div id="rfc.section.1.p.9"><p>In
 addition to encoding method parameters, XML is used in WebDAV to encode
 the responses from methods, providing the extensibility and 
internationalization advantages of XML for method output, as well as 
input.<a class="self" href="#rfc.section.1.p.9">¶</a></p></div><div id="rfc.section.1.p.10"><p>XML elements used in this specification are defined in <a href="#xml.element.definitions" title="XML Element Definitions">Section&nbsp;12</a>.<a class="self" href="#rfc.section.1.p.10">¶</a></p></div><div id="rfc.section.1.p.11"><p>The XML namespace extension (<a href="#xml.namespaces.for.webdav" title="Appendix 4 -- XML Namespaces for WebDAV">Appendix&nbsp;23.4</a>)
 is also used in this specification in order to allow for new XML 
elements to be added without fear of colliding with other element names.<a class="self" href="#rfc.section.1.p.11">¶</a></p></div><div id="rfc.section.1.p.12"><p>While
 the status codes provided by HTTP/1.1 are sufficient to describe most 
error conditions encountered by WebDAV methods, there are some errors 
that do not fall neatly into the existing categories. New status codes 
developed for the WebDAV methods are defined in <a href="#status.code.extensions.to.http11" title="Status Code Extensions to HTTP/1.1">Section&nbsp;10</a>.
 Since some WebDAV methods may operate over many resources, the 
Multi-Status response has been introduced to return status information 
for multiple resources. The Multi-Status response is described in <a href="#multi-status.response" title="Multi-Status Response">Section&nbsp;11</a>.<a class="self" href="#rfc.section.1.p.12">¶</a></p></div><div id="rfc.section.1.p.13"><p>WebDAV
 employs the property mechanism to store information about the current 
state of the resource. For example, when a lock is taken out on a 
resource, a lock information property describes the current state of the
 lock. <a href="#dav.properties" title="DAV Properties">Section&nbsp;13</a> defines the properties used within the WebDAV specification.<a class="self" href="#rfc.section.1.p.13">¶</a></p></div><div id="rfc.section.1.p.14"><p>Finishing off the specification are sections on what it means to be compliant with this specification (<a href="#dav.compliance.classes" title="DAV Compliance Classes">Section&nbsp;15</a>), on internationalization support (<a href="#internationalization.considerations" title="Internationalization Considerations">Section&nbsp;16</a>), and on security (<a href="#security.considerations" title="Security Considerations">Section&nbsp;17</a>).<a class="self" href="#rfc.section.1.p.14">¶</a></p></div></section><section id="n-notational-conventions"><h2 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#n-notational-conventions">Notational Conventions</a></h2><div id="rfc.section.2.p.1"><p>Since
 this document describes a set of extensions to the HTTP/1.1 protocol, 
the augmented BNF used herein to describe protocol elements is exactly 
the same as described in section <a href="https://tools.ietf.org/html/rfc2068#section-2.1" id="rfc.xref.RFC2068.1">2.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. Since this augmented BNF uses the basic production rules provided in section <a href="https://tools.ietf.org/html/rfc2068#section-2.2" id="rfc.xref.RFC2068.3">2.2</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, these rules apply to this document as well.<a class="self" href="#rfc.section.2.p.1">¶</a></p></div><div id="rfc.section.2.p.2"><p>The
 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.<a class="self" href="#rfc.section.2.p.2">¶</a></p></div></section><section id="n-terminology"><h2 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#n-terminology">Terminology</a></h2><div id="rfc.section.3.p.1"><p><span id="rfc.iref.u.1"></span> <span id="rfc.iref.u.2"></span> <dfn>URI</dfn>/<dfn>URL</dfn>
 - A Uniform Resource Identifier and Uniform Resource Locator, 
respectively. These terms (and the distinction between them) are defined
 in <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>.<a class="self" href="#rfc.section.3.p.1">¶</a></p></div><div id="rfc.section.3.p.2"><p><span id="rfc.iref.c.1"></span> <dfn>Collection</dfn> - A resource that contains a set of URIs, termed member URIs, which identify member resources and meets the requirements in <a href="#collections.of.web.resources" title="Collections of Web Resources">Section&nbsp;5</a> of this specification.<a class="self" href="#rfc.section.3.p.2">¶</a></p></div><div id="rfc.section.3.p.3"><p><span id="rfc.iref.m.1"></span> <dfn>Member URI</dfn> - A URI which is a member of the set of URIs contained by a collection.<a class="self" href="#rfc.section.3.p.3">¶</a></p></div><div id="rfc.section.3.p.4"><p><span id="rfc.iref.i.1"></span> <dfn>Internal Member URI</dfn> - A Member URI that is immediately relative to the URI of the collection (the definition of immediately relative is given in <a href="#collection.resources" title="Collection Resources">Section&nbsp;5.2</a>).<a class="self" href="#rfc.section.3.p.4">¶</a></p></div><div id="rfc.section.3.p.5"><p><span id="rfc.iref.p.1"></span> <dfn>Property</dfn> - A name/value pair that contains descriptive information about a resource.<a class="self" href="#rfc.section.3.p.5">¶</a></p></div><div id="rfc.section.3.p.6"><p><span id="rfc.iref.l.1"></span> <dfn>Live Property</dfn>
 - A property whose semantics and syntax are enforced by the server. For
 example, the live "getcontentlength" property has its value, the length
 of the entity returned by a GET request, automatically calculated by 
the server.<a class="self" href="#rfc.section.3.p.6">¶</a></p></div><div id="rfc.section.3.p.7"><p><span id="rfc.iref.d.1"></span> <dfn>Dead Property</dfn>
 - A property whose semantics and syntax are not enforced by the server.
 The server only records the value of a dead property; the client is 
responsible for maintaining the consistency of the syntax and semantics 
of a dead property.<a class="self" href="#rfc.section.3.p.7">¶</a></p></div><div id="rfc.section.3.p.8"><p><span id="rfc.iref.n.1"></span> <dfn>Null Resource</dfn>
 - A resource which responds with a 404 (Not Found) to any HTTP/1.1 or 
DAV method except for PUT, MKCOL, OPTIONS and LOCK. A NULL resource <em class="bcp14">MUST NOT</em> appear as a member of its parent collection.<a class="self" href="#rfc.section.3.p.8">¶</a></p></div></section><section id="data.model.for.resource.properties"><h2 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#data.model.for.resource.properties">Data Model for Resource Properties</a></h2><section id="n-the-resource-property-model"><h3 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a href="#n-the-resource-property-model">The Resource Property Model</a></h3><div id="rfc.section.4.1.p.1"><p>Properties are pieces of data that describe the state of a resource. Properties are data about data.<a class="self" href="#rfc.section.4.1.p.1">¶</a></p></div><div id="rfc.section.4.1.p.2"><p>Properties
 are used in distributed authoring environments to provide for efficient
 discovery and management of resources. For example, a 'subject' 
property might allow for the indexing of all resources by their subject,
 and an 'author' property might allow for the discovery of what authors 
have written which documents.<a class="self" href="#rfc.section.4.1.p.2">¶</a></p></div><div id="rfc.section.4.1.p.3"><p>The
 DAV property model consists of name/value pairs. The name of a property
 identifies the property's syntax and semantics, and provides an address
 by which to refer to its syntax and semantics.<a class="self" href="#rfc.section.4.1.p.3">¶</a></p></div><div id="rfc.section.4.1.p.4"><p>There
 are two categories of properties: "live" and "dead". A live property 
has its syntax and semantics enforced by the server. Live properties 
include cases where a) the value of a property is read-only, maintained 
by the server, and b) the value of the property is maintained by the 
client, but the server performs syntax checking on submitted values. All
 instances of a given live property <em class="bcp14">MUST</em> comply 
with the definition associated with that property name. A dead property 
has its syntax and semantics enforced by the client; the server merely 
records the value of the property verbatim.<a class="self" href="#rfc.section.4.1.p.4">¶</a></p></div></section><section id="n-existing-metadata-proposals"><h3 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a href="#n-existing-metadata-proposals">Existing Metadata Proposals</a></h3><div id="rfc.section.4.2.p.1"><p>Properties
 have long played an essential role in the maintenance of large document
 repositories, and many current proposals contain some notion of a 
property, or discuss web metadata more generally. These include PICS <a href="#REC-PICS" id="rfc.xref.REC-PICS.1"><cite title="PICS Label Distribution Label Syntax and Communication Protocols, Version 1.1">[REC-PICS]</cite></a>,
 PICS-NG, XML, Web Collections, and several proposals on representing 
relationships within HTML. Work on PICS-NG and Web Collections has been 
subsumed by the Resource Description Framework (RDF) metadata activity 
of the World Wide Web Consortium. RDF consists of a network-based data 
model and an XML representation of that model.<a class="self" href="#rfc.section.4.2.p.1">¶</a></p></div><div id="rfc.section.4.2.p.2"><p>Some proposals come from a digital library perspective. These include the Dublin Core <a href="#RFC2413" id="rfc.xref.RFC2413.1"><cite title="Dublin Core Metadata for Resource Discovery">[RFC2413]</cite></a> metadata set and the Warwick Framework <a href="#WF" id="rfc.xref.WF.1"><cite title="The Warwick Framework: A Container Architecture for Diverse Sets of Metadata">[WF]</cite></a>, a container architecture for different metadata schemas. The literature includes many examples of metadata, including MARC <a href="#USMARC" id="rfc.xref.USMARC.1"><cite title="USMARC Format for Bibliographic Data">[USMARC]</cite></a>, a bibliographic metadata format, and a technical report bibliographic format employed by the Dienst system <a href="#RFC1807" id="rfc.xref.RFC1807.1"><cite title="A Format for Bibliographic Records">[RFC1807]</cite></a>. Additionally, the proceedings from the first IEEE Metadata conference describe many community-specific metadata sets.<a class="self" href="#rfc.section.4.2.p.2">¶</a></p></div><div id="rfc.section.4.2.p.3"><p>Participants of the 1996 Metadata II Workshop in Warwick, UK <a href="#WF" id="rfc.xref.WF.2"><cite title="The Warwick Framework: A Container Architecture for Diverse Sets of Metadata">[WF]</cite></a>,
 noted that "new metadata sets will develop as the networked 
infrastructure matures" and "different communities will propose, design,
 and be responsible for different types of metadata." These observations
 can be corroborated by noting that many community-specific sets of 
metadata already exist, and there is significant motivation for the 
development of new forms of metadata as many communities increasingly 
make their data available in digital form, requiring a metadata format 
to assist data location and cataloging.<a class="self" href="#rfc.section.4.2.p.3">¶</a></p></div></section><section id="n-properties-and-http-headers"><h3 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a href="#n-properties-and-http-headers">Properties and HTTP Headers</a></h3><div id="rfc.section.4.3.p.1"><p>Properties
 already exist, in a limited sense, in HTTP message headers. However, in
 distributed authoring environments a relatively large number of 
properties are needed to describe the state of a resource, and 
setting/returning them all through HTTP headers is inefficient. Thus a 
mechanism is needed which allows a principal to identify a set of 
properties in which the principal is interested and to set or retrieve 
just those properties.<a class="self" href="#rfc.section.4.3.p.1">¶</a></p></div></section><section id="n-property-values"><h3 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a href="#n-property-values">Property Values</a></h3><div id="rfc.section.4.4.p.1"><p>The value of a property when expressed in XML <em class="bcp14">MUST</em> be well formed.<a class="self" href="#rfc.section.4.4.p.1">¶</a></p></div><div id="rfc.section.4.4.p.2"><p>XML
 has been chosen because it is a flexible, self-describing, structured 
data format that supports rich schema definitions, and because of its 
support for multiple character sets. XML's self-describing nature allows
 any property's value to be extended by adding new elements. Older 
clients will not break when they encounter extensions because they will 
still have the data specified in the original schema and will ignore 
elements they do not understand. XML's support for multiple character 
sets allows any human-readable property to be encoded and read in a 
character set familiar to the user. XML's support for multiple human 
languages, using the "xml:lang" attribute, handles cases where the same 
character set is employed by multiple human languages.<a class="self" href="#rfc.section.4.4.p.2">¶</a></p></div></section><section id="n-property-names"><h3 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a>&nbsp;<a href="#n-property-names">Property Names</a></h3><div id="rfc.section.4.5.p.1"><p>A
 property name is a universally unique identifier that is associated 
with a schema that provides information about the syntax and semantics 
of the property.<a class="self" href="#rfc.section.4.5.p.1">¶</a></p></div><div id="rfc.section.4.5.p.2"><p>Because
 a property's name is universally unique, clients can depend upon 
consistent behavior for a particular property across multiple resources,
 on the same and across different servers, so long as that property is 
"live" on the resources in question, and the implementation of the live 
property is faithful to its definition.<a class="self" href="#rfc.section.4.5.p.2">¶</a></p></div><div id="rfc.section.4.5.p.3"><p>The XML namespace mechanism, which is based on URIs <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>,
 is used to name properties because it prevents namespace collisions and
 provides for varying degrees of administrative control.<a class="self" href="#rfc.section.4.5.p.3">¶</a></p></div><div id="rfc.section.4.5.p.4"><p>The
 property namespace is flat; that is, no hierarchy of properties is 
explicitly recognized. Thus, if a property A and a property A/B exist on
 a resource, there is no recognition of any relationship between the two
 properties. It is expected that a separate specification will 
eventually be produced which will address issues relating to 
hierarchical properties.<a class="self" href="#rfc.section.4.5.p.4">¶</a></p></div><div id="rfc.section.4.5.p.5"><p>Finally,
 it is not possible to define the same property twice on a single 
resource, as this would cause a collision in the resource's property 
namespace.<a class="self" href="#rfc.section.4.5.p.5">¶</a></p></div></section><section id="n-media-independent-links"><h3 id="rfc.section.4.6"><a href="#rfc.section.4.6">4.6</a>&nbsp;<a href="#n-media-independent-links">Media Independent Links</a></h3><div id="rfc.section.4.6.p.1"><p>Although
 HTML resources support links to other resources, the Web needs more 
general support for links between resources of any media type (media 
types are also known as MIME types, or content types). WebDAV provides 
such links. A WebDAV link is a special type of property value, formally 
defined in <a href="#ELEMENT_link" title="link XML Element">Section&nbsp;12.4</a>,
 that allows typed connections to be established between resources of 
any media type. The property value consists of source and destination 
Uniform Resource Identifiers (URIs); the property name identifies the 
link type.<a class="self" href="#rfc.section.4.6.p.1">¶</a></p></div></section></section><section id="collections.of.web.resources"><h2 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a href="#collections.of.web.resources">Collections of Web Resources</a></h2><div id="rfc.section.5.p.1"><p>This
 section provides a description of a new type of Web resource, the 
collection, and discusses its interactions with the HTTP URL namespace. 
The purpose of a collection resource is to model collection-like objects
 (e.g., file system directories) within a server's namespace.<a class="self" href="#rfc.section.5.p.1">¶</a></p></div><div id="rfc.section.5.p.2"><p>All DAV compliant resources <em class="bcp14">MUST</em> support the HTTP URL namespace model specified herein.<a class="self" href="#rfc.section.5.p.2">¶</a></p></div><section id="http.url.namespace.model"><h3 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a href="#http.url.namespace.model">HTTP URL Namespace Model</a></h3><div id="rfc.section.5.1.p.1"><p>The HTTP URL namespace is a hierarchical namespace where the hierarchy is delimited with the "/" character.<a class="self" href="#rfc.section.5.1.p.1">¶</a></p></div><div id="rfc.section.5.1.p.2"><p>An
 HTTP URL namespace is said to be consistent if it meets the following 
conditions: for every URL in the HTTP hierarchy there exists a 
collection that contains that URL as an internal member. The root, or 
top-level collection of the namespace under consideration is exempt from
 the previous rule.<a class="self" href="#rfc.section.5.1.p.2">¶</a></p></div><div id="rfc.section.5.1.p.3"><p>Neither
 HTTP/1.1 nor WebDAV require that the entire HTTP URL namespace be 
consistent. However, certain WebDAV methods are prohibited from 
producing results that cause namespace inconsistencies.<a class="self" href="#rfc.section.5.1.p.3">¶</a></p></div><div id="rfc.section.5.1.p.4"><p>Although implicit in <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2396" id="rfc.xref.RFC2396.3"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, any resource, including collection resources, <em class="bcp14">MAY</em> be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.<a class="self" href="#rfc.section.5.1.p.4">¶</a></p></div></section><section id="collection.resources"><h3 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a href="#collection.resources">Collection Resources</a></h3><div id="rfc.section.5.2.p.1"><p>A
 collection is a resource whose state consists of at least a list of 
internal member URIs and a set of properties, but which may have 
additional state such as entity bodies returned by GET. An internal 
member URI <em class="bcp14">MUST</em> be immediately relative to a base
 URI of the collection. That is, the internal member URI is equal to a 
containing collection's URI plus an additional segment for 
non-collection resources, or additional segment plus trailing slash "/" 
for collection resources, where segment is defined in section <a href="https://tools.ietf.org/html/rfc2396#section-3.3" id="rfc.xref.RFC2396.4">3.3</a> of <a href="#RFC2396" id="rfc.xref.RFC2396.5"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>.<a class="self" href="#rfc.section.5.2.p.1">¶</a></p></div><div id="rfc.section.5.2.p.2"><p>Any given internal member URI <em class="bcp14">MUST</em>
 only belong to the collection once, i.e., it is illegal to have 
multiple instances of the same URI in a collection. Properties defined 
on collections behave exactly as do properties on non-collection 
resources.<a class="self" href="#rfc.section.5.2.p.2">¶</a></p></div><div id="rfc.section.5.2.p.3"><p>For all WebDAV compliant resources A and B, identified by URIs U and V, for which U is immediately relative to V, B <em class="bcp14">MUST</em>
 be a collection that has U as an internal member URI. So, if the 
resource with URL http://foo.com/bar/blah is WebDAV compliant and if the
 resource with URL http://foo.com/bar/ is WebDAV compliant then the 
resource with URL http://foo.com/bar/ must be a collection and must 
contain URL http://foo.com/bar/blah as an internal member.<a class="self" href="#rfc.section.5.2.p.3">¶</a></p></div><div id="rfc.section.5.2.p.4"><p>Collection resources <em class="bcp14">MAY</em>
 list the URLs of non-WebDAV compliant children in the HTTP URL 
namespace hierarchy as internal members but are not required to do so. 
For example, if the resource with URL http://foo.com/bar/blah is not 
WebDAV compliant and the URL http://foo.com/bar/ identifies a collection
 then URL http://foo.com/bar/blah may or may not be an internal member 
of the collection with URL http://foo.com/bar/.<a class="self" href="#rfc.section.5.2.p.4">¶</a></p></div><div id="rfc.section.5.2.p.5"><p>If
 a WebDAV compliant resource has no WebDAV compliant children in the 
HTTP URL namespace hierarchy then the WebDAV compliant resource is not 
required to be a collection.<a class="self" href="#rfc.section.5.2.p.5">¶</a></p></div><div id="rfc.section.5.2.p.6"><p>There
 is a standing convention that when a collection is referred to by its 
name without a trailing slash, the trailing slash is automatically 
appended. Due to this, a resource may accept a URI without a trailing 
"/" to point to a collection. In this case it <em class="bcp14">SHOULD</em>
 return a content-location header in the response pointing to the URI 
ending with the "/". For example, if a client invokes a method on 
http://foo.bar/blah (no trailing slash), the resource 
http://foo.bar/blah/ (trailing slash) may respond as if the operation 
were invoked on it, and should return a content-location header with 
http://foo.bar/blah/ in it. In general clients <em class="bcp14">SHOULD</em> use the "/" form of collection names.<a class="self" href="#rfc.section.5.2.p.6">¶</a></p></div><div id="rfc.section.5.2.p.7"><p>A resource <em class="bcp14">MAY</em>
 be a collection but not be WebDAV compliant. That is, the resource may 
comply with all the rules set out in this specification regarding how a 
collection is to behave without necessarily supporting all methods that a
 WebDAV compliant resource is required to support. In such a case the 
resource may return the DAV:resourcetype property with the value 
DAV:collection but <em class="bcp14">MUST NOT</em> return a DAV header containing the value "1" on an OPTIONS response.<a class="self" href="#rfc.section.5.2.p.7">¶</a></p></div></section><section id="n-creation-and-retrieval-of-collection-resources"><h3 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a href="#n-creation-and-retrieval-of-collection-resources">Creation and Retrieval of Collection Resources</a></h3><div id="rfc.section.5.3.p.1" class="avoidbreakafter"><p>This
 document specifies the MKCOL method to create new collection resources,
 rather than using the existing HTTP/1.1 PUT or POST method, for the 
following reasons:<a class="self" href="#rfc.section.5.3.p.1">¶</a></p></div><div id="rfc.section.5.3.p.2"><p>In
 HTTP/1.1, the PUT method is defined to store the request body at the 
location specified by the Request-URI. While a description format for a 
collection can readily be constructed for use with PUT, the implications
 of sending such a description to the server are undesirable. For 
example, if a description of a collection that omitted some existing 
resources were PUT to a server, this might be interpreted as a command 
to remove those members. This would extend PUT to perform DELETE 
functionality, which is undesirable since it changes the semantics of 
PUT, and makes it difficult to control DELETE functionality with an 
access control scheme based on methods.<a class="self" href="#rfc.section.5.3.p.2">¶</a></p></div><div id="rfc.section.5.3.p.3"><p>While
 the POST method is sufficiently open-ended that a "create a collection"
 POST command could be constructed, this is undesirable because it would
 be difficult to separate access control for collection creation from 
other uses of POST.<a class="self" href="#rfc.section.5.3.p.3">¶</a></p></div><div id="rfc.section.5.3.p.4"><p>The exact definition of the behavior of GET and PUT on collections is defined later in this document.<a class="self" href="#rfc.section.5.3.p.4">¶</a></p></div></section><section id="n-source-resources-and-output-resources"><h3 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a href="#n-source-resources-and-output-resources">Source Resources and Output Resources</a></h3><div id="rfc.section.5.4.p.1"><p>For
 many resources, the entity returned by a GET method exactly matches the
 persistent state of the resource, for example, a GIF file stored on a 
disk. For this simple case, the URI at which a resource is accessed is 
identical to the URI at which the source (the persistent state) of the 
resource is accessed. This is also the case for HTML source files that 
are not processed by the server prior to transmission.<a class="self" href="#rfc.section.5.4.p.1">¶</a></p></div><div id="rfc.section.5.4.p.2"><p>However,
 the server can sometimes process HTML resources before they are 
transmitted as a return entity body. For example, a server-side-include 
directive within an HTML file might instruct a server to replace the 
directive with another value, such as the current date. In this case, 
what is returned by GET (HTML plus date) differs from the persistent 
state of the resource (HTML plus directive). Typically there is no way 
to access the HTML resource containing the unprocessed directive.<a class="self" href="#rfc.section.5.4.p.2">¶</a></p></div><div id="rfc.section.5.4.p.3"><p>Sometimes
 the entity returned by GET is the output of a data-producing process 
that is described by one or more source resources (that may not even 
have a location in the URI namespace). A single data-producing process 
may dynamically generate the state of a potentially large number of 
output resources. An example of this is a CGI script that describes a 
"finger" gateway process that maps part of the namespace of a server 
into finger requests, such as 
http://www.foo.bar.org/finger_gateway/user@host.<a class="self" href="#rfc.section.5.4.p.3">¶</a></p></div><div id="rfc.section.5.4.p.4"><p>In
 the absence of distributed authoring capabilities, it is acceptable to 
have no mapping of source resource(s) to the URI namespace. In fact, 
preventing access to the source resource(s) has desirable security 
benefits. However, if remote editing of the source resource(s) is 
desired, the source resource(s) should be given a location in the URI 
namespace. This source location should not be one of the locations at 
which the generated output is retrievable, since in general it is 
impossible for the server to differentiate requests for source resources
 from requests for process output resources. There is often a 
many-to-many relationship between source resources and output resources.<a class="self" href="#rfc.section.5.4.p.4">¶</a></p></div><div id="rfc.section.5.4.p.5"><p>On
 WebDAV compliant servers the URI of the source resource(s) may be 
stored in a link on the output resource with type DAV:source (see <a href="#PROPERTY_source" title="source Property">Section&nbsp;13.10</a>
 for a description of the source link property). Storing the source URIs
 in links on the output resources places the burden of discovering the 
source on the authoring client. Note that the value of a source link is 
not guaranteed to point to the correct source. Source links may break or
 incorrect values may be entered. Also note that not all servers will 
allow the client to set the source link value. For example a server 
which generates source links on the fly for its CGI files will most 
likely not allow a client to set the source link value.<a class="self" href="#rfc.section.5.4.p.5">¶</a></p></div></section></section><section id="locking"><h2 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a href="#locking">Locking</a></h2><div id="rfc.section.6.p.1"><p>The
 ability to lock a resource provides a mechanism for serializing access 
to that resource. Using a lock, an authoring client can provide a 
reasonable guarantee that another principal will not modify a resource 
while it is being edited. In this way, a client can prevent the "lost 
update" problem.<a class="self" href="#rfc.section.6.p.1">¶</a></p></div><div id="rfc.section.6.p.2"><p>This
 specification allows locks to vary over two client-specified 
parameters, the number of principals involved (exclusive vs. shared) and
 the type of access to be granted. This document defines locking for 
only one access type, write. However, the syntax is extensible, and 
permits the eventual specification of locking for other access types.<a class="self" href="#rfc.section.6.p.2">¶</a></p></div><section id="n-exclusive-vs.-shared-locks"><h3 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a href="#n-exclusive-vs.-shared-locks">Exclusive Vs. Shared Locks</a></h3><div id="rfc.section.6.1.p.1"><p>The
 most basic form of lock is an exclusive lock. This is a lock where the 
access right in question is only granted to a single principal. The need
 for this arbitration results from a desire to avoid having to merge 
results.<a class="self" href="#rfc.section.6.1.p.1">¶</a></p></div><div id="rfc.section.6.1.p.2"><p>However,
 there are times when the goal of a lock is not to exclude others from 
exercising an access right but rather to provide a mechanism for 
principals to indicate that they intend to exercise their access rights.
 Shared locks are provided for this case. A shared lock allows multiple 
principals to receive a lock. Hence any principal with appropriate 
access can get the lock.<a class="self" href="#rfc.section.6.1.p.2">¶</a></p></div><div id="rfc.section.6.1.p.3"><p>With
 shared locks there are two trust sets that affect a resource. The first
 trust set is created by access permissions. Principals who are trusted,
 for example, may have permission to write to the resource. Among those 
who have access permission to write to the resource, the set of 
principals who have taken out a shared lock also must trust each other, 
creating a (typically) smaller trust set within the access permission 
write set.<a class="self" href="#rfc.section.6.1.p.3">¶</a></p></div><div id="rfc.section.6.1.p.4"><p>Starting
 with every possible principal on the Internet, in most situations the 
vast majority of these principals will not have write access to a given 
resource. Of the small number who do have write access, some principals 
may decide to guarantee their edits are free from overwrite conflicts by
 using exclusive write locks. Others may decide they trust their 
collaborators will not overwrite their work (the potential set of 
collaborators being the set of principals who have write permission) and
 use a shared lock, which informs their collaborators that a principal 
may be working on the resource.<a class="self" href="#rfc.section.6.1.p.4">¶</a></p></div><div id="rfc.section.6.1.p.5"><p>The
 WebDAV extensions to HTTP do not need to provide all of the 
communications paths necessary for principals to coordinate their 
activities. When using shared locks, principals may use any out of band 
communication channel to coordinate their work (e.g., face-to-face 
interaction, written notes, post-it notes on the screen, telephone 
conversation, Email, etc.) The intent of a shared lock is to let 
collaborators know who else may be working on a resource.<a class="self" href="#rfc.section.6.1.p.5">¶</a></p></div><div id="rfc.section.6.1.p.6"><p>Shared
 locks are included because experience from web distributed authoring 
systems has indicated that exclusive locks are often too rigid. An 
exclusive lock is used to enforce a particular editing process: take out
 an exclusive lock, read the resource, perform edits, write the 
resource, release the lock. This editing process has the problem that 
locks are not always properly released, for example when a program 
crashes, or when a lock owner leaves without unlocking a resource. While
 both timeouts and administrative action can be used to remove an 
offending lock, neither mechanism may be available when needed; the 
timeout may be long or the administrator may not be available.<a class="self" href="#rfc.section.6.1.p.6">¶</a></p></div></section><section id="n-required-support"><h3 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a href="#n-required-support">Required Support</a></h3><div id="rfc.section.6.2.p.1"><p>A
 WebDAV compliant server is not required to support locking in any form.
 If the server does support locking it may choose to support any 
combination of exclusive and shared locks for any access types.<a class="self" href="#rfc.section.6.2.p.1">¶</a></p></div><div id="rfc.section.6.2.p.2"><p>The
 reason for this flexibility is that locking policy strikes to the very 
heart of the resource management and versioning systems employed by 
various storage repositories. These repositories require control over 
what sort of locking will be made available. For example, some 
repositories only support shared write locks while others only provide 
support for exclusive write locks while yet others use no locking at 
all. As each system is sufficiently different to merit exclusion of 
certain locking features, this specification leaves locking as the sole 
axis of negotiation within WebDAV.<a class="self" href="#rfc.section.6.2.p.2">¶</a></p></div></section><section id="n-lock-tokens"><h3 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a href="#n-lock-tokens">Lock Tokens</a></h3><div id="rfc.section.6.3.p.1"><p>A
 lock token is a type of state token, represented as a URI, which 
identifies a particular lock. A lock token is returned by every 
successful LOCK operation in the lockdiscovery property in the response 
body, and can also be found through lock discovery on a resource.<a class="self" href="#rfc.section.6.3.p.1">¶</a></p></div><div id="rfc.section.6.3.p.2"><p>Lock token URIs <em class="bcp14">MUST</em>
 be unique across all resources for all time. This uniqueness constraint
 allows lock tokens to be submitted across resources and servers without
 fear of confusion.<a class="self" href="#rfc.section.6.3.p.2">¶</a></p></div><div id="rfc.section.6.3.p.3"><p>This
 specification provides a lock token URI scheme called opaquelocktoken 
that meets the uniqueness requirements. However resources are free to 
return any URI scheme so long as it meets the uniqueness requirements.<a class="self" href="#rfc.section.6.3.p.3">¶</a></p></div><div id="rfc.section.6.3.p.4"><p>Having
 a lock token provides no special access rights. Anyone can find out 
anyone else's lock token by performing lock discovery. Locks <em class="bcp14">MUST</em> be enforced based upon whatever authentication mechanism is used by the server, not based on the secrecy of the token values.<a class="self" href="#rfc.section.6.3.p.4">¶</a></p></div></section><section id="opaquelocktoken.lock.token.uri.scheme"><h3 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a href="#opaquelocktoken.lock.token.uri.scheme">opaquelocktoken Lock Token URI Scheme</a></h3><div id="rfc.section.6.4.p.1"><p>The
 opaquelocktoken URI scheme is designed to be unique across all 
resources for all time. Due to this uniqueness quality, a client may 
submit an opaque lock token in an If header on a resource other than the
 one that returned it.<a class="self" href="#rfc.section.6.4.p.1">¶</a></p></div><div id="rfc.section.6.4.p.2"><p>All resources <em class="bcp14">MUST</em>
 recognize the opaquelocktoken scheme and, at minimum, recognize that 
the lock token does not refer to an outstanding lock on the resource.<a class="self" href="#rfc.section.6.4.p.2">¶</a></p></div><div id="rfc.section.6.4.p.3"><p>In
 order to guarantee uniqueness across all resources for all time the 
opaquelocktoken requires the use of the Universal Unique Identifier 
(UUID) mechanism, as described in <a href="#ISO-11578" id="rfc.xref.ISO-11578.1"><cite title="ISO/IEC 11578:1996. Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)">[ISO-11578]</cite></a>.<a class="self" href="#rfc.section.6.4.p.3">¶</a></p></div><div id="rfc.section.6.4.p.4"><p>Opaquelocktoken
 generators, however, have a choice of how they create these tokens. 
They can either generate a new UUID for every lock token they create or 
they can create a single UUID and then add extension characters. If the 
second method is selected then the program generating the extensions <em class="bcp14">MUST</em> guarantee that the same extension will never be used twice with the associated UUID.<a class="self" href="#rfc.section.6.4.p.4">¶</a></p></div><div id="rfc.section.6.4.p.5"><p>OpaqueLockToken-URI
 = "opaquelocktoken:" UUID [Extension] ; The UUID production is the 
string representation of a UUID, as defined in <a href="#ISO-11578" id="rfc.xref.ISO-11578.2"><cite title="ISO/IEC 11578:1996. Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)">[ISO-11578]</cite></a>. Note that white space (LWS) is not allowed between elements of this production.<a class="self" href="#rfc.section.6.4.p.5">¶</a></p></div><div id="rfc.section.6.4.p.6"><p>Extension = path ; path is defined in section <a href="https://tools.ietf.org/html/rfc2068#section-3.2.1" id="rfc.xref.RFC2068.6">3.2.1</a> of RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> <a class="self" href="#rfc.section.6.4.p.6">¶</a></p></div><section id="node.field.generation.without.the.ieee.802.address"><h4 id="rfc.section.6.4.1"><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;<a href="#node.field.generation.without.the.ieee.802.address">Node Field Generation Without the IEEE 802 Address</a></h4><div id="rfc.section.6.4.1.p.1"><p>UUIDs, as defined in <a href="#ISO-11578" id="rfc.xref.ISO-11578.3"><cite title="ISO/IEC 11578:1996. Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)">[ISO-11578]</cite></a>, contain a "node" field that contains one of the IEEE 802 addresses for the server machine. As noted in <a href="#risks.connected.with.lock.tokens" title="Risks Connected with Lock Tokens">Section&nbsp;17.8</a>,
 there are several security risks associated with exposing a machine's 
IEEE 802 address. This section provides an alternate mechanism for 
generating the "node" field of a UUID which does not employ an IEEE 802 
address. WebDAV servers <em class="bcp14">MAY</em> use this algorithm 
for creating the node field when generating UUIDs. The text in this 
section is originally from an Internet-Draft by Paul Leach and Rich 
Salz, who are noted here to properly attribute their work.<a class="self" href="#rfc.section.6.4.1.p.1">¶</a></p></div><div id="rfc.section.6.4.1.p.2"><p>The
 ideal solution is to obtain a 47 bit cryptographic quality random 
number, and use it as the low 47 bits of the node ID, with the most 
significant bit of the first octet of the node ID set to 1. This bit is 
the unicast/multicast bit, which will never be set in IEEE 802 addresses
 obtained from network cards; hence, there can never be a conflict 
between UUIDs generated by machines with and without network cards.<a class="self" href="#rfc.section.6.4.1.p.2">¶</a></p></div><div id="rfc.section.6.4.1.p.3" class="avoidbreakafter"><p>If
 a system does not have a primitive to generate cryptographic quality 
random numbers, then in most systems there are usually a fairly large 
number of sources of randomness available from which one can be 
generated. Such sources are system specific, but often include:<a class="self" href="#rfc.section.6.4.1.p.3">¶</a></p></div><div id="rfc.section.6.4.1.p.4"><ul><li>the percent of memory in use</li><li>the size of main memory in bytes</li><li>the amount of free main memory in bytes</li><li>the size of the paging or swap file in bytes</li><li>free bytes of paging or swap file</li><li>the total size of user virtual address space in bytes</li><li>the total available user address space bytes</li><li>the size of boot disk drive in bytes</li><li>the free disk space on boot drive in bytes</li><li>the current time</li><li>the amount of time since the system booted</li><li>the individual sizes of files in various system directories</li><li>the creation, last read, and modification times of files in various system directories</li><li>the utilization factors of various system resources (heap, etc.)</li><li>current mouse cursor position</li><li>current caret position</li><li>current number of running processes, threads</li><li>handles or IDs of the desktop window and the active window</li><li>the value of stack pointer of the caller</li><li>the process and thread ID of caller</li><li>various processor architecture specific performance counters (instructions executed, cache misses, TLB misses)</li></ul></div><div id="rfc.section.6.4.1.p.5"><p>(Note
 that it is precisely the above kinds of sources of randomness that are 
used to seed cryptographic quality random number generators on systems 
without special hardware for their construction.)<a class="self" href="#rfc.section.6.4.1.p.5">¶</a></p></div><div id="rfc.section.6.4.1.p.6"><p>In
 addition, items such as the computer's name and the name of the 
operating system, while not strictly speaking random, will help 
differentiate the results from those obtained by other systems.<a class="self" href="#rfc.section.6.4.1.p.6">¶</a></p></div><div id="rfc.section.6.4.1.p.7"><p>The
 exact algorithm to generate a node ID using these data is system 
specific, because both the data available and the functions to obtain 
them are often very system specific. However, assuming that one can 
concatenate all the values from the randomness sources into a buffer, 
and that a cryptographic hash function such as MD5 is available, then 
any 6 bytes of the MD5 hash of the buffer, with the multicast bit (the 
high bit of the first byte) set will be an appropriately random node ID.<a class="self" href="#rfc.section.6.4.1.p.7">¶</a></p></div><div id="rfc.section.6.4.1.p.8"><p>Other
 hash functions, such as SHA-1, can also be used. The only requirement 
is that the result be suitably random _ in the sense that the outputs 
from a set uniformly distributed inputs are themselves uniformly 
distributed, and that a single bit change in the input can be expected 
to cause half of the output bits to change.<a class="self" href="#rfc.section.6.4.1.p.8">¶</a></p></div></section></section><section id="n-lock-capability-discovery"><h3 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a href="#n-lock-capability-discovery">Lock Capability Discovery</a></h3><div id="rfc.section.6.5.p.1"><p>Since
 server lock support is optional, a client trying to lock a resource on a
 server can either try the lock and hope for the best, or perform some 
form of discovery to determine what lock capabilities the server 
supports. This is known as lock capability discovery. Lock capability 
discovery differs from discovery of supported access control types, 
since there may be access control types without corresponding lock 
types. A client can determine what lock types the server supports by 
retrieving the supportedlock property.<a class="self" href="#rfc.section.6.5.p.1">¶</a></p></div><div id="rfc.section.6.5.p.2"><p>Any DAV compliant resource that supports the LOCK method <em class="bcp14">MUST</em> support the supportedlock property.<a class="self" href="#rfc.section.6.5.p.2">¶</a></p></div></section><section id="n-active-lock-discovery"><h3 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a href="#n-active-lock-discovery">Active Lock Discovery</a></h3><div id="rfc.section.6.6.p.1"><p>If
 another principal locks a resource that a principal wishes to access, 
it is useful for the second principal to be able to find out who the 
first principal is. For this purpose the lockdiscovery property is 
provided. This property lists all outstanding locks, describes their 
type, and where available, provides their lock token.<a class="self" href="#rfc.section.6.6.p.1">¶</a></p></div><div id="rfc.section.6.6.p.2"><p>Any DAV compliant resource that supports the LOCK method <em class="bcp14">MUST</em> support the lockdiscovery property.<a class="self" href="#rfc.section.6.6.p.2">¶</a></p></div></section><section id="n-usage-considerations"><h3 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a>&nbsp;<a href="#n-usage-considerations">Usage Considerations</a></h3><div id="rfc.section.6.7.p.1" class="avoidbreakafter"><p>Although
 the locking mechanisms specified here provide some help in preventing 
lost updates, they cannot guarantee that updates will never be lost. 
Consider the following scenario:<a class="self" href="#rfc.section.6.7.p.1">¶</a></p></div><div id="rfc.section.6.7.p.2"><p>Two
 clients A and B are interested in editing the resource ' index.html'. 
Client A is an HTTP client rather than a WebDAV client, and so does not 
know how to perform locking.<a class="self" href="#rfc.section.6.7.p.2">¶</a></p></div><div id="rfc.section.6.7.p.3"><p>Client A doesn't lock the document, but does a GET and begins editing.<a class="self" href="#rfc.section.6.7.p.3">¶</a></p></div><div id="rfc.section.6.7.p.4"><p>Client B does LOCK, performs a GET and begins editing.<a class="self" href="#rfc.section.6.7.p.4">¶</a></p></div><div id="rfc.section.6.7.p.5"><p>Client B finishes editing, performs a PUT, then an UNLOCK.<a class="self" href="#rfc.section.6.7.p.5">¶</a></p></div><div id="rfc.section.6.7.p.6"><p>Client A performs a PUT, overwriting and losing all of B's changes.<a class="self" href="#rfc.section.6.7.p.6">¶</a></p></div><div id="rfc.section.6.7.p.7"><p>There
 are several reasons why the WebDAV protocol itself cannot prevent this 
situation. First, it cannot force all clients to use locking because it 
must be compatible with HTTP clients that do not comprehend locking. 
Second, it cannot require servers to support locking because of the 
variety of repository implementations, some of which rely on 
reservations and merging rather than on locking. Finally, being 
stateless, it cannot enforce a sequence of operations like LOCK / GET / 
PUT / UNLOCK.<a class="self" href="#rfc.section.6.7.p.7">¶</a></p></div><div id="rfc.section.6.7.p.8"><p>WebDAV
 servers that support locking can reduce the likelihood that clients 
will accidentally overwrite each other's changes by requiring clients to
 lock resources before modifying them. Such servers would effectively 
prevent HTTP 1.0 and HTTP 1.1 clients from modifying resources.<a class="self" href="#rfc.section.6.7.p.8">¶</a></p></div><div id="rfc.section.6.7.p.9"><p>WebDAV
 clients can be good citizens by using a lock / retrieve / write /unlock
 sequence of operations (at least by default) whenever they interact 
with a WebDAV server that supports locking.<a class="self" href="#rfc.section.6.7.p.9">¶</a></p></div><div id="rfc.section.6.7.p.10"><p>HTTP
 1.1 clients can be good citizens, avoiding overwriting other clients' 
changes, by using entity tags in If-Match headers with any requests that
 would modify resources.<a class="self" href="#rfc.section.6.7.p.10">¶</a></p></div><div id="rfc.section.6.7.p.11"><p>Information
 managers may attempt to prevent overwrites by implementing client-side 
procedures requiring locking before modifying WebDAV resources.<a class="self" href="#rfc.section.6.7.p.11">¶</a></p></div></section></section><section id="n-write-lock"><h2 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a href="#n-write-lock">Write Lock</a></h2><div id="rfc.section.7.p.1"><p>This
 section describes the semantics specific to the write lock type. The 
write lock is a specific instance of a lock type, and is the only lock 
type described in this specification.<a class="self" href="#rfc.section.7.p.1">¶</a></p></div><section id="n-methods-restricted-by-write-locks"><h3 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a href="#n-methods-restricted-by-write-locks">Methods Restricted by Write Locks</a></h3><div id="rfc.section.7.1.p.1"><p>A write lock <em class="bcp14">MUST</em>
 prevent a principal without the lock from successfully executing a PUT,
 POST, PROPPATCH, LOCK, UNLOCK, MOVE, DELETE, or MKCOL on the locked 
resource. All other current methods, GET in particular, function 
independently of the lock.<a class="self" href="#rfc.section.7.1.p.1">¶</a></p></div><div id="rfc.section.7.1.p.2"><p>Note, however, that as new methods are created it will be necessary to specify how they interact with a write lock.<a class="self" href="#rfc.section.7.1.p.2">¶</a></p></div></section><section id="n-write-locks-and-lock-tokens"><h3 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a href="#n-write-locks-and-lock-tokens">Write Locks and Lock Tokens</a></h3><div id="rfc.section.7.2.p.1"><p>A successful request for an exclusive or shared write lock <em class="bcp14">MUST</em>
 result in the generation of a unique lock token associated with the 
requesting principal. Thus if five principals have a shared write lock 
on the same resource there will be five lock tokens, one for each 
principal.<a class="self" href="#rfc.section.7.2.p.1">¶</a></p></div></section><section id="n-write-locks-and-properties"><h3 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a href="#n-write-locks-and-properties">Write Locks and Properties</a></h3><div id="rfc.section.7.3.p.1"><p>While
 those without a write lock may not alter a property on a resource it is
 still possible for the values of live properties to change, even while 
locked, due to the requirements of their schemas. Only dead properties 
and live properties defined to respect locks are guaranteed not to 
change while write locked.<a class="self" href="#rfc.section.7.3.p.1">¶</a></p></div></section><section id="n-write-locks-and-null-resources"><h3 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a>&nbsp;<a href="#n-write-locks-and-null-resources">Write Locks and Null Resources</a></h3><div id="rfc.section.7.4.p.1"><p>It is possible to assert a write lock on a null resource in order to lock the name.<a class="self" href="#rfc.section.7.4.p.1">¶</a></p></div><div id="rfc.section.7.4.p.2"><p>A write locked null resource, referred to as a lock-null resource, <em class="bcp14">MUST</em>
 respond with a 404 (Not Found) or 405 (Method Not Allowed) to any 
HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, 
and UNLOCK. A lock-null resource <em class="bcp14">MUST</em> appear as a member of its parent collection. Additionally the lock-null resource <em class="bcp14">MUST</em>
 have defined on it all mandatory DAV properties. Most of these 
properties, such as all the get* properties, will have no value as a 
lock-null resource does not support the GET method. Lock-Null resources <em class="bcp14">MUST</em> have defined values for lockdiscovery and supportedlock properties.<a class="self" href="#rfc.section.7.4.p.2">¶</a></p></div><div id="rfc.section.7.4.p.3"><p>Until a method such as PUT or MKCOL is successfully executed on the lock-null resource the resource <em class="bcp14">MUST</em>
 stay in the lock-null state. However, once a PUT or MKCOL is 
successfully executed on a lock-null resource the resource ceases to be 
in the lock-null state.<a class="self" href="#rfc.section.7.4.p.3">¶</a></p></div><div id="rfc.section.7.4.p.4"><p>If
 the resource is unlocked, for any reason, without a PUT, MKCOL, or 
similar method having been successfully executed upon it then the 
resource <em class="bcp14">MUST</em> return to the null state.<a class="self" href="#rfc.section.7.4.p.4">¶</a></p></div></section><section id="write.locks.and.collections"><h3 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a href="#write.locks.and.collections">Write Locks and Collections</a></h3><div id="rfc.section.7.5.p.1"><p>A
 write lock on a collection, whether created by a "Depth: 0" or "Depth: 
infinity" lock request, prevents the addition or removal of member URIs 
of the collection by non-lock owners. As a consequence, when a principal
 issues a PUT or POST request to create a new resource under a URI which
 needs to be an internal member of a write locked collection to maintain
 HTTP namespace consistency, or issues a DELETE to remove a resource 
which has a URI which is an existing internal member URI of a write 
locked collection, this request <em class="bcp14">MUST</em> fail if the principal does not have a write lock on the collection.<a class="self" href="#rfc.section.7.5.p.1">¶</a></p></div><div id="rfc.section.7.5.p.2"><p>However,
 if a write lock request is issued to a collection containing member 
URIs identifying resources that are currently locked in a manner which 
conflicts with the write lock, the request <em class="bcp14">MUST</em> fail with a 423 (Locked) status code.<a class="self" href="#rfc.section.7.5.p.2">¶</a></p></div><div id="rfc.section.7.5.p.3"><p>If a lock owner causes the URI of a resource to be added as an internal member URI of a locked collection then the new resource <em class="bcp14">MUST</em>
 be automatically added to the lock. This is the only mechanism that 
allows a resource to be added to a write lock. Thus, for example, if the
 collection /a/b/ is write locked and the resource /c is moved to /a/b/c
 then resource /a/b/c will be added to the write lock.<a class="self" href="#rfc.section.7.5.p.3">¶</a></p></div></section><section id="write.locks.and.the.if.request.header"><h3 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a>&nbsp;<a href="#write.locks.and.the.if.request.header">Write Locks and the If Request Header</a></h3><div id="rfc.section.7.6.p.1"><p>If
 a user agent is not required to have knowledge about a lock when 
requesting an operation on a locked resource, the following scenario 
might occur. Program A, run by User A, takes out a write lock on a 
resource. Program B, also run by User A, has no knowledge of the lock 
taken out by Program A, yet performs a PUT to the locked resource. In 
this scenario, the PUT succeeds because locks are associated with a 
principal, not a program, and thus program B, because it is acting with 
principal A's credential, is allowed to perform the PUT. However, had 
program B known about the lock, it would not have overwritten the 
resource, preferring instead to present a dialog box describing the 
conflict to the user. Due to this scenario, a mechanism is needed to 
prevent different programs from accidentally ignoring locks taken out by
 other programs with the same authorization.<a class="self" href="#rfc.section.7.6.p.1">¶</a></p></div><div id="rfc.section.7.6.p.2"><p>In order to prevent these collisions a lock token <em class="bcp14">MUST</em>
 be submitted by an authorized principal in the If header for all locked
 resources that a method may interact with or the method <em class="bcp14">MUST</em>
 fail. For example, if a resource is to be moved and both the source and
 destination are locked then two lock tokens must be submitted, one for 
the source and the other for the destination.<a class="self" href="#rfc.section.7.6.p.2">¶</a></p></div><section id="n-example---write-lock"><h4 id="rfc.section.7.6.1"><a href="#rfc.section.7.6.1">7.6.1</a>&nbsp;<a href="#n-example---write-lock">Example - Write Lock</a></h4><div id="rfc.figure.u.1"><p>&gt;&gt;Request</p><pre class="text2">   COPY /~fielding/index.html HTTP/1.1
   Host: www.ics.uci.edu
   Destination: http://www.ics.uci.edu/users/f/fielding/index.html
   If: &lt;http://www.ics.uci.edu/users/f/fielding/index.html&gt;
       (&lt;opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6&gt;)
</pre></div><div id="rfc.figure.u.2"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 204 No Content
</pre></div><div id="rfc.section.7.6.1.p.1"><p>In this example, even 
though both the source and destination are locked, only one lock token 
must be submitted, for the lock on the destination. This is because the 
source resource is not modified by a COPY, and hence unaffected by the 
write lock. In this example, user agent authentication has previously 
occurred via a mechanism outside the scope of the HTTP protocol, in the 
underlying transport layer.<a class="self" href="#rfc.section.7.6.1.p.1">¶</a></p></div></section></section><section id="n-write-locks-and-copy-move"><h3 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a>&nbsp;<a href="#n-write-locks-and-copy-move">Write Locks and COPY/MOVE</a></h3><div id="rfc.section.7.7.p.1"><p>A COPY method invocation <em class="bcp14">MUST NOT</em>
 duplicate any write locks active on the source. However, as previously 
noted, if the COPY copies the resource into a collection that is locked 
with "Depth: infinity", then the resource will be added to the lock.<a class="self" href="#rfc.section.7.7.p.1">¶</a></p></div><div id="rfc.section.7.7.p.2"><p>A successful MOVE request on a write locked resource <em class="bcp14">MUST NOT</em>
 move the write lock with the resource. However, the resource is subject
 to being added to an existing lock at the destination, as specified in <a href="#write.locks.and.collections" title="Write Locks and Collections">Section&nbsp;7.5</a>.
 For example, if the MOVE makes the resource a child of a collection 
that is locked with "Depth: infinity", then the resource will be added 
to that collection's lock. Additionally, if a resource locked with 
"Depth: infinity" is moved to a destination that is within the scope of 
the same lock (e.g., within the namespace tree covered by the lock), the
 moved resource will again be a added to the lock. In both these 
examples, as specified in <a href="#write.locks.and.the.if.request.header" title="Write Locks and the If Request Header">Section&nbsp;7.6</a>, an If header must be submitted containing a lock token for both the source and destination.<a class="self" href="#rfc.section.7.7.p.2">¶</a></p></div></section><section id="n-refreshing-write-locks"><h3 id="rfc.section.7.8"><a href="#rfc.section.7.8">7.8</a>&nbsp;<a href="#n-refreshing-write-locks">Refreshing Write Locks</a></h3><div id="rfc.section.7.8.p.1"><p>A client <em class="bcp14">MUST NOT</em>
 submit the same write lock request twice. Note that a client is always 
aware it is resubmitting the same lock request because it must include 
the lock token in the If header in order to make the request for a 
resource that is already locked.<a class="self" href="#rfc.section.7.8.p.1">¶</a></p></div><div id="rfc.section.7.8.p.2"><p>However, a client may submit a LOCK method with an If header but without a body. This form of LOCK <em class="bcp14">MUST</em> only be used to "refresh" a lock. Meaning, at minimum, that any timers associated with the lock <em class="bcp14">MUST</em> be re-set.<a class="self" href="#rfc.section.7.8.p.2">¶</a></p></div><div id="rfc.section.7.8.p.3"><p>A
 server may return a Timeout header with a lock refresh that is 
different than the Timeout header returned when the lock was originally 
requested. Additionally clients may submit Timeout headers of arbitrary 
value with their lock refresh requests. Servers, as always, may ignore 
Timeout headers submitted by the client.<a class="self" href="#rfc.section.7.8.p.3">¶</a></p></div><div id="rfc.section.7.8.p.4"><p>If an error is received in response to a refresh LOCK request the client <em class="bcp14">SHOULD</em> assume that the lock was not refreshed.<a class="self" href="#rfc.section.7.8.p.4">¶</a></p></div></section></section><section id="http.methods.for.distributed.authoring"><h2 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a href="#http.methods.for.distributed.authoring">HTTP Methods for Distributed Authoring</a></h2><div id="rfc.section.8.p.1"><p>The following new HTTP methods use XML as a request and response format. All DAV compliant clients and resources <em class="bcp14">MUST</em> use XML parsers that are compliant with <a href="#REC-XML" id="rfc.xref.REC-XML.2"><cite title="Extensible Markup Language (XML) 1.0">[REC-XML]</cite></a>. All XML used in either requests or responses <em class="bcp14">MUST</em> be, at minimum, well formed. If a server receives ill-formed XML in a request it <em class="bcp14">MUST</em> reject the entire request with a 400 (Bad Request). If a client receives ill-formed XML in a response then it <em class="bcp14">MUST NOT</em> assume anything about the outcome of the executed method and <em class="bcp14">SHOULD</em> treat the server as malfunctioning.<a class="self" href="#rfc.section.8.p.1">¶</a></p></div><section id="METHOD_PROPFIND"><h3 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a href="#METHOD_PROPFIND">PROPFIND</a></h3><div id="rfc.section.8.1.p.1"><p>The
 PROPFIND method retrieves properties defined on the resource identified
 by the Request-URI, if the resource does not have any internal members,
 or on the resource identified by the Request-URI and potentially its 
member resources, if the resource is a collection that has internal 
member URIs. All DAV compliant resources <em class="bcp14">MUST</em> support the PROPFIND method and the propfind XML element (section <a href="#ELEMENT_propfind" title="propfind XML Element">12.14</a>) along with all XML elements defined for use with that element.<a class="self" href="#rfc.section.8.1.p.1">¶</a></p></div><div id="rfc.section.8.1.p.2"><p>A
 client may submit a Depth header with a value of "0", "1", or 
"infinity" with a PROPFIND on a collection resource with internal member
 URIs. DAV compliant servers <em class="bcp14">MUST</em> support the "0", "1" and "infinity" behaviors. By default, the PROPFIND method without a Depth header <em class="bcp14">MUST</em> act as if a "Depth: infinity" header was included.<a class="self" href="#rfc.section.8.1.p.2">¶</a></p></div><div id="rfc.section.8.1.p.3"><p>A
 client may submit a propfind XML element in the body of the request 
method describing what information is being requested. It is possible to
 request particular property values, all property values, or a list of 
the names of the resource's properties. A client may choose not to 
submit a request body. An empty PROPFIND request body <em class="bcp14">MUST</em> be treated as a request for the names and values of all properties.<a class="self" href="#rfc.section.8.1.p.3">¶</a></p></div><div id="rfc.section.8.1.p.4"><p>All servers <em class="bcp14">MUST</em>
 support returning a response of content type text/xml or 
application/xml that contains a multistatus XML element that describes 
the results of the attempts to retrieve the various properties.<a class="self" href="#rfc.section.8.1.p.4">¶</a></p></div><div id="rfc.section.8.1.p.5"><p>If there is an error retrieving a property then a proper error result <em class="bcp14">MUST</em> be included in the response. A request to retrieve the value of a property which does not exist is an error and <em class="bcp14">MUST</em>
 be noted, if the response uses a multistatus XML element, with a 
response XML element which contains a 404 (Not Found) status value.<a class="self" href="#rfc.section.8.1.p.5">¶</a></p></div><div id="rfc.section.8.1.p.6"><p>Consequently, the multistatus XML element for a collection resource with member URIs <em class="bcp14">MUST</em>
 include a response XML element for each member URI of the collection, 
to whatever depth was requested. Each response XML element <em class="bcp14">MUST</em>
 contain an href XML element that gives the URI of the resource on which
 the properties in the prop XML element are defined. Results for a 
PROPFIND on a collection resource with internal member URIs are returned
 as a flat list whose order of entries is not significant.<a class="self" href="#rfc.section.8.1.p.6">¶</a></p></div><div id="rfc.section.8.1.p.7"><p>In
 the case of allprop and propname, if a principal does not have the 
right to know whether a particular property exists then the property 
should be silently excluded from the response.<a class="self" href="#rfc.section.8.1.p.7">¶</a></p></div><div id="rfc.section.8.1.p.8"><p>The results of this method <em class="bcp14">SHOULD NOT</em> be cached.<a class="self" href="#rfc.section.8.1.p.8">¶</a></p></div><section id="n-example---retrieving-named-properties"><h4 id="rfc.section.8.1.1"><a href="#rfc.section.8.1.1">8.1.1</a>&nbsp;<a href="#n-example---retrieving-named-properties">Example - Retrieving Named Properties</a></h4><div id="rfc.figure.u.3"><p>&gt;&gt;Request</p><pre class="text2">   PROPFIND  /file HTTP/1.1
   Host: www.foo.bar
   Content-type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:propfind xmlns:D="DAV:"&gt;
     &lt;D:prop xmlns:R="http://www.foo.bar/boxschema/"&gt;
          &lt;R:bigbox/&gt;
          &lt;R:author/&gt;
          &lt;R:DingALing/&gt;
          &lt;R:Random/&gt;
     &lt;/D:prop&gt;
   &lt;/D:propfind&gt;
</pre></div><div id="rfc.figure.u.4"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:multistatus xmlns:D="DAV:"&gt;
     &lt;D:response&gt;
          &lt;D:href&gt;http://www.foo.bar/file&lt;/D:href&gt;
          &lt;D:propstat&gt;
               &lt;D:prop xmlns:R="http://www.foo.bar/boxschema/"&gt;
                    &lt;R:bigbox&gt;
                         &lt;R:BoxType&gt;Box type A&lt;/R:BoxType&gt;
                    &lt;/R:bigbox&gt;
                    &lt;R:author&gt;
                         &lt;R:Name&gt;J.J. Johnson&lt;/R:Name&gt;
                    &lt;/R:author&gt;
               &lt;/D:prop&gt;
               &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt;
          &lt;/D:propstat&gt;
          &lt;D:propstat&gt;
               &lt;D:prop&gt;&lt;R:DingALing/&gt;&lt;R:Random/&gt;&lt;/D:prop&gt;
               &lt;D:status&gt;HTTP/1.1 403 Forbidden&lt;/D:status&gt;
               &lt;D:responsedescription&gt; The user does not have access to
   the DingALing property.
               &lt;/D:responsedescription&gt;
          &lt;/D:propstat&gt;
     &lt;/D:response&gt;
     &lt;D:responsedescription&gt; There has been an access violation error.
     &lt;/D:responsedescription&gt;
   &lt;/D:multistatus&gt;
</pre></div><div id="rfc.section.8.1.1.p.1"><p>In this example, PROPFIND
 is executed on a non-collection resource http://www.foo.bar/file. The 
propfind XML element specifies the name of four properties whose values 
are being requested. In this case only two properties were returned, 
since the principal issuing the request did not have sufficient access 
rights to see the third and fourth properties.<a class="self" href="#rfc.section.8.1.1.p.1">¶</a></p></div></section><section id="n-example---using-allprop-to-retrieve-all-properties"><h4 id="rfc.section.8.1.2"><a href="#rfc.section.8.1.2">8.1.2</a>&nbsp;<a href="#n-example---using-allprop-to-retrieve-all-properties">Example - Using allprop to Retrieve All Properties</a></h4><div id="rfc.figure.u.5"><p>&gt;&gt;Request</p><pre class="text2">   PROPFIND  /container/ HTTP/1.1
   Host: www.foo.bar
   Depth: 1
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:propfind xmlns:D="DAV:"&gt;
     &lt;D:allprop/&gt;
   &lt;/D:propfind&gt;
</pre></div><div id="rfc.figure.u.6"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:multistatus xmlns:D="DAV:"&gt;
     &lt;D:response&gt;
          &lt;D:href&gt;http://www.foo.bar/container/&lt;/D:href&gt;
          &lt;D:propstat&gt;
               &lt;D:prop xmlns:R="http://www.foo.bar/boxschema/"&gt;
                    &lt;R:bigbox&gt;
                         &lt;R:BoxType&gt;Box type A&lt;/R:BoxType&gt;
                    &lt;/R:bigbox&gt;
                    &lt;R:author&gt;
                         &lt;R:Name&gt;Hadrian&lt;/R:Name&gt;
                    &lt;/R:author&gt;
                    &lt;D:creationdate&gt;
                         1997-12-01T17:42:21-08:00
                    &lt;/D:creationdate&gt;
                    &lt;D:displayname&gt;
                         Example collection
                    &lt;/D:displayname&gt;
                    &lt;D:resourcetype&gt;&lt;D:collection/&gt;&lt;/D:resourcetype&gt;
                    &lt;D:supportedlock&gt;
                         &lt;D:lockentry&gt;
                              &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
                              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
                         &lt;/D:lockentry&gt;
                         &lt;D:lockentry&gt;
                              &lt;D:lockscope&gt;&lt;D:shared/&gt;&lt;/D:lockscope&gt;
                              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
                         &lt;/D:lockentry&gt;
                    &lt;/D:supportedlock&gt;
               &lt;/D:prop&gt;
               &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt;
          &lt;/D:propstat&gt;
     &lt;/D:response&gt;
     &lt;D:response&gt;
          &lt;D:href&gt;http://www.foo.bar/container/front.html&lt;/D:href&gt;
          &lt;D:propstat&gt;
               &lt;D:prop xmlns:R="http://www.foo.bar/boxschema/"&gt;
                    &lt;R:bigbox&gt;
                         &lt;R:BoxType&gt;Box type B&lt;/R:BoxType&gt;
                    &lt;/R:bigbox&gt;
                    &lt;D:creationdate&gt;
                         1997-12-01T18:27:21-08:00
                    &lt;/D:creationdate&gt;
                    &lt;D:displayname&gt;
                         Example HTML resource
                    &lt;/D:displayname&gt;
                    &lt;D:getcontentlength&gt;
                         4525
                    &lt;/D:getcontentlength&gt;
                    &lt;D:getcontenttype&gt;
                         text/html
                    &lt;/D:getcontenttype&gt;
                    &lt;D:getetag&gt;
                         zzyzx
                    &lt;/D:getetag&gt;
                    &lt;D:getlastmodified&gt;
                         Monday, 12-Jan-98 09:25:56 GMT
                    &lt;/D:getlastmodified&gt;
                    &lt;D:resourcetype/&gt;
                    &lt;D:supportedlock&gt;
                         &lt;D:lockentry&gt;
                              &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
                              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
                         &lt;/D:lockentry&gt;
                         &lt;D:lockentry&gt;
                              &lt;D:lockscope&gt;&lt;D:shared/&gt;&lt;/D:lockscope&gt;
                              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
                         &lt;/D:lockentry&gt;
                    &lt;/D:supportedlock&gt;
               &lt;/D:prop&gt;
               &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt;
          &lt;/D:propstat&gt;
     &lt;/D:response&gt;
   &lt;/D:multistatus&gt;
</pre></div><div id="rfc.section.8.1.2.p.1"><p>In this example, PROPFIND
 was invoked on the resource http://www.foo.bar/container/ with a Depth 
header of 1, meaning the request applies to the resource and its 
children, and a propfind XML element containing the allprop XML element,
 meaning the request should return the name and value of all properties 
defined on each resource.<a class="self" href="#rfc.section.8.1.2.p.1">¶</a></p></div><div id="rfc.section.8.1.2.p.2" class="avoidbreakafter"><p>The resource http://www.foo.bar/container/ has six properties defined on it:<a class="self" href="#rfc.section.8.1.2.p.2">¶</a></p></div><div id="rfc.section.8.1.2.p.3"><p>http://www.foo.bar/boxschema/bigbox,
 http://www.foo.bar/boxschema/author, DAV:creationdate, DAV:displayname,
 DAV:resourcetype, and DAV:supportedlock.<a class="self" href="#rfc.section.8.1.2.p.3">¶</a></p></div><div id="rfc.section.8.1.2.p.4"><p>The last four properties are WebDAV-specific, defined in <a href="#dav.properties" title="DAV Properties">Section&nbsp;13</a>.
 Since GET is not supported on this resource, the get* properties (e.g.,
 getcontentlength) are not defined on this resource. The DAV-specific 
properties assert that "container" was created on December 1, 1997, at 
5:42:21PM, in a time zone 8 hours west of GMT (creationdate), has a name
 of "Example collection" (displayname), a collection resource type 
(resourcetype), and supports exclusive write and shared write locks 
(supportedlock).<a class="self" href="#rfc.section.8.1.2.p.4">¶</a></p></div><div id="rfc.section.8.1.2.p.5" class="avoidbreakafter"><p>The resource http://www.foo.bar/container/front.html has nine properties defined on it:<a class="self" href="#rfc.section.8.1.2.p.5">¶</a></p></div><div id="rfc.section.8.1.2.p.6"><p>http://www.foo.bar/boxschema/bigbox
 (another instance of the "bigbox" property type), DAV:creationdate, 
DAV:displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, 
DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.<a class="self" href="#rfc.section.8.1.2.p.6">¶</a></p></div><div id="rfc.section.8.1.2.p.7"><p>The
 DAV-specific properties assert that "front.html" was created on 
December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT 
(creationdate), has a name of "Example HTML resource" (displayname), a 
content length of 4525 bytes (getcontentlength), a MIME type of 
"text/html" (getcontenttype), an entity tag of "zzyzx" (getetag), was 
last modified on Monday, January 12, 1998, at 09:25:56 GMT 
(getlastmodified), has an empty resource type, meaning that it is not a 
collection (resourcetype), and supports both exclusive write and shared 
write locks (supportedlock).<a class="self" href="#rfc.section.8.1.2.p.7">¶</a></p></div></section><section id="n-example---using-propname-to-retrieve-all-property-names"><h4 id="rfc.section.8.1.3"><a href="#rfc.section.8.1.3">8.1.3</a>&nbsp;<a href="#n-example---using-propname-to-retrieve-all-property-names">Example - Using propname to Retrieve all Property Names</a></h4><div id="rfc.figure.u.7"><p>&gt;&gt;Request</p><pre class="text2">   PROPFIND  /container/ HTTP/1.1
   Host: www.foo.bar
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;propfind xmlns="DAV:"&gt;
     &lt;propname/&gt;
   &lt;/propfind&gt;
</pre></div><div id="rfc.figure.u.8"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;multistatus xmlns="DAV:"&gt;
     &lt;response&gt;
          &lt;href&gt;http://www.foo.bar/container/&lt;/href&gt;
          &lt;propstat&gt;
               &lt;prop xmlns:R="http://www.foo.bar/boxschema/"&gt;
                    &lt;R:bigbox/&gt;
                    &lt;R:author/&gt;
                    &lt;creationdate/&gt;
                    &lt;displayname/&gt;
                    &lt;resourcetype/&gt;
                    &lt;supportedlock/&gt;
               &lt;/prop&gt;
               &lt;status&gt;HTTP/1.1 200 OK&lt;/status&gt;
          &lt;/propstat&gt;
     &lt;/response&gt;
     &lt;response&gt;
          &lt;href&gt;http://www.foo.bar/container/front.html&lt;/href&gt;
          &lt;propstat&gt;
               &lt;prop xmlns:R="http://www.foo.bar/boxschema/"&gt;
                    &lt;R:bigbox/&gt;
                    &lt;creationdate/&gt;
                    &lt;displayname/&gt;
                    &lt;getcontentlength/&gt;
                    &lt;getcontenttype/&gt;
                    &lt;getetag/&gt;
                    &lt;getlastmodified/&gt;
                    &lt;resourcetype/&gt;
                    &lt;supportedlock/&gt;
               &lt;/prop&gt;
               &lt;status&gt;HTTP/1.1 200 OK&lt;/status&gt;
          &lt;/propstat&gt;
     &lt;/response&gt;
   &lt;/multistatus&gt;
</pre></div><div id="rfc.section.8.1.3.p.1"><p>In this example, PROPFIND
 is invoked on the collection resource http://www.foo.bar/container/, 
with a propfind XML element containing the propname XML element, meaning
 the name of all properties should be returned. Since no Depth header is
 present, it assumes its default value of "infinity", meaning the name 
of the properties on the collection and all its progeny should be 
returned.<a class="self" href="#rfc.section.8.1.3.p.1">¶</a></p></div><div id="rfc.section.8.1.3.p.2"><p>Consistent
 with the previous example, resource http://www.foo.bar/container/ has 
six properties defined on it, http://www.foo.bar/boxschema/bigbox, 
http://www.foo.bar/boxschema/author, DAV:creationdate, DAV:displayname, 
DAV:resourcetype, and DAV:supportedlock.<a class="self" href="#rfc.section.8.1.3.p.2">¶</a></p></div><div id="rfc.section.8.1.3.p.3"><p>The
 resource http://www.foo.bar/container/index.html, a member of the 
"container" collection, has nine properties defined on it, 
http://www.foo.bar/boxschema/bigbox, DAV:creationdate, DAV:displayname, 
DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, 
DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.<a class="self" href="#rfc.section.8.1.3.p.3">¶</a></p></div><div id="rfc.section.8.1.3.p.4"><p>This
 example also demonstrates the use of XML namespace scoping, and the 
default namespace. Since the "xmlns" attribute does not contain an 
explicit "shorthand name" (prefix) letter, the namespace applies by 
default to all enclosed elements. Hence, all elements which do not 
explicitly state the namespace to which they belong are members of the 
"DAV:" namespace schema.<a class="self" href="#rfc.section.8.1.3.p.4">¶</a></p></div></section></section><section id="METHOD_PROPPATCH"><h3 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a href="#METHOD_PROPPATCH">PROPPATCH</a></h3><div id="rfc.section.8.2.p.1"><p>The
 PROPPATCH method processes instructions specified in the request body 
to set and/or remove properties defined on the resource identified by 
the Request-URI.<a class="self" href="#rfc.section.8.2.p.1">¶</a></p></div><div id="rfc.section.8.2.p.2"><p>All DAV compliant resources <em class="bcp14">MUST</em> support the PROPPATCH method and <em class="bcp14">MUST</em>
 process instructions that are specified using the propertyupdate, set, 
and remove XML elements of the DAV schema. Execution of the directives 
in this method is, of course, subject to access control constraints. DAV
 compliant resources <em class="bcp14">SHOULD</em> support the setting of arbitrary dead properties.<a class="self" href="#rfc.section.8.2.p.2">¶</a></p></div><div id="rfc.section.8.2.p.3"><p>The request message body of a PROPPATCH method <em class="bcp14">MUST</em> contain the propertyupdate XML element. Instruction processing <em class="bcp14">MUST</em> occur in the order instructions are received (i.e., from top to bottom). Instructions <em class="bcp14">MUST</em> either all be executed or none executed. Thus if any error occurs during processing all executed instructions <em class="bcp14">MUST</em>
 be undone and a proper error result returned. Instruction processing 
details can be found in the definition of the set and remove 
instructions in <a href="#ELEMENT_propertyupdate" title="propertyupdate XML element">Section&nbsp;12.13</a>.<a class="self" href="#rfc.section.8.2.p.3">¶</a></p></div><section id="n-status-codes-for-use-with-207--multi-status-"><h4 id="rfc.section.8.2.1"><a href="#rfc.section.8.2.1">8.2.1</a>&nbsp;<a href="#n-status-codes-for-use-with-207--multi-status-">Status Codes for use with 207 (Multi-Status)</a></h4><div id="rfc.section.8.2.1.p.1"><p>The
 following are examples of response codes one would expect to be used in
 a 207 (Multi-Status) response for this method. Note, however, that 
unless explicitly prohibited any 2/3/4/5xx series response code may be 
used in a 207 (Multi-Status) response.<a class="self" href="#rfc.section.8.2.1.p.1">¶</a></p></div><div id="rfc.section.8.2.1.p.2"><p>200 (OK) - The command succeeded. As there can be a mixture of sets and removes in a body, a 201 (Created) seems inappropriate.<a class="self" href="#rfc.section.8.2.1.p.2">¶</a></p></div><div id="rfc.section.8.2.1.p.3"><p>403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties.<a class="self" href="#rfc.section.8.2.1.p.3">¶</a></p></div><div id="rfc.section.8.2.1.p.4"><p>409
 (Conflict) - The client has provided a value whose semantics are not 
appropriate for the property. This includes trying to set read-only 
properties.<a class="self" href="#rfc.section.8.2.1.p.4">¶</a></p></div><div id="rfc.section.8.2.1.p.5"><p>423
 (Locked) - The specified resource is locked and the client either is 
not a lock owner or the lock type requires a lock token to be submitted 
and the client did not submit it.<a class="self" href="#rfc.section.8.2.1.p.5">¶</a></p></div><div id="rfc.section.8.2.1.p.6"><p>507 (Insufficient Storage) - The server did not have sufficient space to record the property.<a class="self" href="#rfc.section.8.2.1.p.6">¶</a></p></div></section><section id="n-example---proppatch"><h4 id="rfc.section.8.2.2"><a href="#rfc.section.8.2.2">8.2.2</a>&nbsp;<a href="#n-example---proppatch">Example - PROPPATCH</a></h4><div id="rfc.figure.u.9"><p>&gt;&gt;Request</p><pre class="text2">   PROPPATCH /bar.html HTTP/1.1
   Host: www.foo.com
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:propertyupdate xmlns:D="DAV:"
   xmlns:Z="http://www.w3.com/standards/z39.50/"&gt;
     &lt;D:set&gt;
          &lt;D:prop&gt;
               &lt;Z:authors&gt;
                    &lt;Z:Author&gt;Jim Whitehead&lt;/Z:Author&gt;
                    &lt;Z:Author&gt;Roy Fielding&lt;/Z:Author&gt;
               &lt;/Z:authors&gt;
          &lt;/D:prop&gt;
     &lt;/D:set&gt;
     &lt;D:remove&gt;
          &lt;D:prop&gt;&lt;Z:Copyright-Owner/&gt;&lt;/D:prop&gt;
     &lt;/D:remove&gt;
   &lt;/D:propertyupdate&gt;
</pre></div><div id="rfc.figure.u.10"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:multistatus xmlns:D="DAV:"
   xmlns:Z="http://www.w3.com/standards/z39.50"&gt;
     &lt;D:response&gt;
          &lt;D:href&gt;http://www.foo.com/bar.html&lt;/D:href&gt;
          &lt;D:propstat&gt;
               &lt;D:prop&gt;&lt;Z:Authors/&gt;&lt;/D:prop&gt;
               &lt;D:status&gt;HTTP/1.1 424 Failed Dependency&lt;/D:status&gt;
          &lt;/D:propstat&gt;
          &lt;D:propstat&gt;
               &lt;D:prop&gt;&lt;Z:Copyright-Owner/&gt;&lt;/D:prop&gt;
               &lt;D:status&gt;HTTP/1.1 409 Conflict&lt;/D:status&gt;
          &lt;/D:propstat&gt;
          &lt;D:responsedescription&gt; Copyright Owner can not be deleted or
   altered.&lt;/D:responsedescription&gt;
     &lt;/D:response&gt;
   &lt;/D:multistatus&gt;
</pre></div><div id="rfc.section.8.2.2.p.1"><p>In this example, the 
client requests the server to set the value of the 
http://www.w3.com/standards/z39.50/Authors property, and to remove the 
property http://www.w3.com/standards/z39.50/Copyright-Owner. Since the 
Copyright-Owner property could not be removed, no property modifications
 occur. The 424 (Failed Dependency) status code for the Authors property
 indicates this action would have succeeded if it were not for the 
conflict with removing the Copyright-Owner property.<a class="self" href="#rfc.section.8.2.2.p.1">¶</a></p></div></section></section><section id="METHOD_MKCOL"><h3 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a href="#METHOD_MKCOL">MKCOL Method</a></h3><div id="rfc.section.8.3.p.1"><p>The MKCOL method is used to create a new collection. All DAV compliant resources <em class="bcp14">MUST</em> support the MKCOL method.<a class="self" href="#rfc.section.8.3.p.1">¶</a></p></div><section id="n-request"><h4 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;<a href="#n-request">Request</a></h4><div id="rfc.section.8.3.1.p.1"><p>MKCOL
 creates a new collection resource at the location specified by the 
Request-URI. If the resource identified by the Request-URI is non-null 
then the MKCOL <em class="bcp14">MUST</em> fail. During MKCOL processing, a server <em class="bcp14">MUST</em> make the Request-URI a member of its parent collection, unless the Request-URI is "/". If no such ancestor exists, the method <em class="bcp14">MUST</em> fail. When the MKCOL operation creates a new collection resource, all ancestors <em class="bcp14">MUST</em> already exist, or the method <em class="bcp14">MUST</em>
 fail with a 409 (Conflict) status code. For example, if a request to 
create collection /a/b/c/d/ is made, and neither /a/b/ nor /a/b/c/ 
exists, the request must fail.<a class="self" href="#rfc.section.8.3.1.p.1">¶</a></p></div><div id="rfc.section.8.3.1.p.2"><p>When MKCOL is invoked without a request body, the newly created collection <em class="bcp14">SHOULD</em> have no members.<a class="self" href="#rfc.section.8.3.1.p.2">¶</a></p></div><div id="rfc.section.8.3.1.p.3"><p>A
 MKCOL request message may contain a message body. The behavior of a 
MKCOL request when the body is present is limited to creating 
collections, members of a collection, bodies of members and properties 
on the collections or members. If the server receives a MKCOL request 
entity type it does not support or understand it <em class="bcp14">MUST</em>
 respond with a 415 (Unsupported Media Type) status code. The exact 
behavior of MKCOL for various request media types is undefined in this 
document, and will be specified in separate documents.<a class="self" href="#rfc.section.8.3.1.p.3">¶</a></p></div></section><section id="n-status-codes_1"><h4 id="rfc.section.8.3.2"><a href="#rfc.section.8.3.2">8.3.2</a>&nbsp;<a href="#n-status-codes_1">Status Codes</a></h4><div id="rfc.section.8.3.2.p.1"><p>Responses from a MKCOL request <em class="bcp14">MUST NOT</em> be cached as MKCOL has non-idempotent semantics.<a class="self" href="#rfc.section.8.3.2.p.1">¶</a></p></div><div id="rfc.section.8.3.2.p.2"><p>201 (Created) - The collection or structured resource was created in its entirety.<a class="self" href="#rfc.section.8.3.2.p.2">¶</a></p></div><div id="rfc.section.8.3.2.p.3"><p>403
 (Forbidden) - This indicates at least one of two conditions: 1) the 
server does not allow the creation of collections at the given location 
in its namespace, or 2) the parent collection of the Request-URI exists 
but cannot accept members.<a class="self" href="#rfc.section.8.3.2.p.3">¶</a></p></div><div id="rfc.section.8.3.2.p.4"><p>405 (Method Not Allowed) - MKCOL can only be executed on a deleted/non-existent resource.<a class="self" href="#rfc.section.8.3.2.p.4">¶</a></p></div><div id="rfc.section.8.3.2.p.5"><p>409 (Conflict) - A collection cannot be made at the Request-URI until one or more intermediate collections have been created.<a class="self" href="#rfc.section.8.3.2.p.5">¶</a></p></div><div id="rfc.section.8.3.2.p.6"><p>415 (Unsupported Media Type)- The server does not support the request type of the body.<a class="self" href="#rfc.section.8.3.2.p.6">¶</a></p></div><div id="rfc.section.8.3.2.p.7"><p>507
 (Insufficient Storage) - The resource does not have sufficient space to
 record the state of the resource after the execution of this method.<a class="self" href="#rfc.section.8.3.2.p.7">¶</a></p></div></section><section id="n-example---mkcol"><h4 id="rfc.section.8.3.3"><a href="#rfc.section.8.3.3">8.3.3</a>&nbsp;<a href="#n-example---mkcol">Example - MKCOL</a></h4><div id="rfc.section.8.3.3.p.1"><p>This example creates a collection called /webdisc/xfiles/ on the server www.server.org.<a class="self" href="#rfc.section.8.3.3.p.1">¶</a></p></div><div id="rfc.figure.u.11"><p>&gt;&gt;Request</p><pre class="text2">   MKCOL /webdisc/xfiles/ HTTP/1.1
   Host: www.server.org
</pre></div><div id="rfc.figure.u.12"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 201 Created
</pre></div></section></section><section id="n-get--head-for-collections"><h3 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a href="#n-get--head-for-collections">GET, HEAD for Collections</a></h3><div id="rfc.section.8.4.p.1"><p>The
 semantics of GET are unchanged when applied to a collection, since GET 
is defined as, "retrieve whatever information (in the form of an entity)
 is identified by the Request-URI" <a href="#RFC2068" id="rfc.xref.RFC2068.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
 GET when applied to a collection may return the contents of an 
"index.html" resource, a human-readable view of the contents of the 
collection, or something else altogether. Hence it is possible that the 
result of a GET on a collection will bear no correlation to the 
membership of the collection.<a class="self" href="#rfc.section.8.4.p.1">¶</a></p></div><div id="rfc.section.8.4.p.2"><p>Similarly,
 since the definition of HEAD is a GET without a response message body, 
the semantics of HEAD are unmodified when applied to collection 
resources.<a class="self" href="#rfc.section.8.4.p.2">¶</a></p></div></section><section id="n-post-for-collections"><h3 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a href="#n-post-for-collections">POST for Collections</a></h3><div id="rfc.section.8.5.p.1"><p>Since
 by definition the actual function performed by POST is determined by 
the server and often depends on the particular resource, the behavior of
 POST when applied to collections cannot be meaningfully modified 
because it is largely undefined. Thus the semantics of POST are 
unmodified when applied to a collection.<a class="self" href="#rfc.section.8.5.p.1">¶</a></p></div></section><section id="METHOD_DELETE"><h3 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a>&nbsp;<a href="#METHOD_DELETE">DELETE</a></h3><section id="n-delete-for-non-collection-resources"><h4 id="rfc.section.8.6.1"><a href="#rfc.section.8.6.1">8.6.1</a>&nbsp;<a href="#n-delete-for-non-collection-resources">DELETE for Non-Collection Resources</a></h4><div id="rfc.section.8.6.1.p.1"><p>If
 the DELETE method is issued to a non-collection resource whose URIs are
 an internal member of one or more collections, then during DELETE 
processing a server <em class="bcp14">MUST</em> remove any URI for the resource identified by the Request-URI from collections which contain it as a member.<a class="self" href="#rfc.section.8.6.1.p.1">¶</a></p></div></section><section id="n-delete-for-collections"><h4 id="rfc.section.8.6.2"><a href="#rfc.section.8.6.2">8.6.2</a>&nbsp;<a href="#n-delete-for-collections">DELETE for Collections</a></h4><div id="rfc.section.8.6.2.p.1"><p>The DELETE method on a collection <em class="bcp14">MUST</em> act as if a "Depth: infinity" header was used on it. A client <em class="bcp14">MUST NOT</em> submit a Depth header with a DELETE on a collection with any value but infinity.<a class="self" href="#rfc.section.8.6.2.p.1">¶</a></p></div><div id="rfc.section.8.6.2.p.2"><p>DELETE
 instructs that the collection specified in the Request-URI and all 
resources identified by its internal member URIs are to be deleted.<a class="self" href="#rfc.section.8.6.2.p.2">¶</a></p></div><div id="rfc.section.8.6.2.p.3"><p>If any resource identified by a member URI cannot be deleted then all of the member's ancestors <em class="bcp14">MUST NOT</em> be deleted, so as to maintain namespace consistency.<a class="self" href="#rfc.section.8.6.2.p.3">¶</a></p></div><div id="rfc.section.8.6.2.p.4"><p>Any headers included with DELETE <em class="bcp14">MUST</em> be applied in processing every resource to be deleted.<a class="self" href="#rfc.section.8.6.2.p.4">¶</a></p></div><div id="rfc.section.8.6.2.p.5"><p>When the DELETE method has completed processing it <em class="bcp14">MUST</em> result in a consistent namespace.<a class="self" href="#rfc.section.8.6.2.p.5">¶</a></p></div><div id="rfc.section.8.6.2.p.6"><p>If an error occurs with a resource other than the resource identified in the Request-URI then the response <em class="bcp14">MUST</em> be a 207 (Multi-Status). 424 (Failed Dependency) errors <em class="bcp14">SHOULD NOT</em>
 be in the 207 (Multi-Status). They can be safely left out because the 
client will know that the ancestors of a resource could not be deleted 
when the client receives an error for the ancestor's progeny. 
Additionally 204 (No Content) errors <em class="bcp14">SHOULD NOT</em> be returned in the 207 (Multi-Status). The reason for this prohibition is that 204 (No Content) is the default success code.<a class="self" href="#rfc.section.8.6.2.p.6">¶</a></p></div><section id="n-example---delete"><h5 id="rfc.section.8.6.2.1"><a href="#rfc.section.8.6.2.1">8.6.2.1</a>&nbsp;<a href="#n-example---delete">Example - DELETE</a></h5><div id="rfc.figure.u.13"><p>&gt;&gt;Request</p><pre class="text2">   DELETE  /container/ HTTP/1.1
   Host: www.foo.bar
</pre></div><div id="rfc.figure.u.14"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;d:multistatus xmlns:d="DAV:"&gt;
     &lt;d:response&gt;
          &lt;d:href&gt;http://www.foo.bar/container/resource3&lt;/d:href&gt;
          &lt;d:status&gt;HTTP/1.1 423 Locked&lt;/d:status&gt;
     &lt;/d:response&gt;
   &lt;/d:multistatus&gt;
</pre></div><div id="rfc.section.8.6.2.1.p.1"><p>In this example the 
attempt to delete http://www.foo.bar/container/resource3 failed because 
it is locked, and no lock token was submitted with the request. 
Consequently, the attempt to delete http://www.foo.bar/container/ also 
failed. Thus the client knows that the attempt to delete 
http://www.foo.bar/container/ must have also failed since the parent can
 not be deleted unless its child has also been deleted. Even though a 
Depth header has not been included, a depth of infinity is assumed 
because the method is on a collection.<a class="self" href="#rfc.section.8.6.2.1.p.1">¶</a></p></div></section></section></section><section id="METHOD_PUT"><h3 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a>&nbsp;<a href="#METHOD_PUT">PUT</a></h3><section id="n-put-for-non-collection-resources"><h4 id="rfc.section.8.7.1"><a href="#rfc.section.8.7.1">8.7.1</a>&nbsp;<a href="#n-put-for-non-collection-resources">PUT for Non-Collection Resources</a></h4><div id="rfc.section.8.7.1.p.1"><p>A
 PUT performed on an existing resource replaces the GET response entity 
of the resource. Properties defined on the resource may be recomputed 
during PUT processing but are not otherwise affected. For example, if a 
server recognizes the content type of the request body, it may be able 
to automatically extract information that could be profitably exposed as
 properties.<a class="self" href="#rfc.section.8.7.1.p.1">¶</a></p></div><div id="rfc.section.8.7.1.p.2"><p>A PUT that would result in the creation of a resource without an appropriately scoped parent collection <em class="bcp14">MUST</em> fail with a 409 (Conflict).<a class="self" href="#rfc.section.8.7.1.p.2">¶</a></p></div></section><section id="n-put-for-collections"><h4 id="rfc.section.8.7.2"><a href="#rfc.section.8.7.2">8.7.2</a>&nbsp;<a href="#n-put-for-collections">PUT for Collections</a></h4><div id="rfc.section.8.7.2.p.1"><p>As defined in the HTTP/1.1 specification <a href="#RFC2068" id="rfc.xref.RFC2068.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>,
 the "PUT method requests that the enclosed entity be stored under the 
supplied Request-URI." Since submission of an entity representing a 
collection would implicitly encode creation and deletion of resources, 
this specification intentionally does not define a transmission format 
for creating a collection using PUT. Instead, the MKCOL method is 
defined to create collections.<a class="self" href="#rfc.section.8.7.2.p.1">¶</a></p></div><div id="rfc.section.8.7.2.p.2"><p>When the PUT operation creates a new non-collection resource all ancestors <em class="bcp14">MUST</em> already exist. If all ancestors do not exist, the method <em class="bcp14">MUST</em>
 fail with a 409 (Conflict) status code. For example, if resource 
/a/b/c/d.html is to be created and /a/b/c/ does not exist, then the 
request must fail.<a class="self" href="#rfc.section.8.7.2.p.2">¶</a></p></div></section></section><section id="METHOD_COPY"><h3 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a>&nbsp;<a href="#METHOD_COPY">COPY Method</a></h3><div id="rfc.section.8.8.p.1"><p>The
 COPY method creates a duplicate of the source resource, identified by 
the Request-URI, in the destination resource, identified by the URI in 
the Destination header. The Destination header <em class="bcp14">MUST</em> be present. The exact behavior of the COPY method depends on the type of the source resource.<a class="self" href="#rfc.section.8.8.p.1">¶</a></p></div><div id="rfc.section.8.8.p.2"><p>All WebDAV compliant resources <em class="bcp14">MUST</em>
 support the COPY method. However, support for the COPY method does not 
guarantee the ability to copy a resource. For example, separate programs
 may control resources on the same server. As a result, it may not be 
possible to copy a resource to a location that appears to be on the same
 server.<a class="self" href="#rfc.section.8.8.p.2">¶</a></p></div><section id="n-copy-for-http-1.1-resources"><h4 id="rfc.section.8.8.1"><a href="#rfc.section.8.8.1">8.8.1</a>&nbsp;<a href="#n-copy-for-http-1.1-resources">COPY for HTTP/1.1 resources</a></h4><div id="rfc.section.8.8.1.p.1"><p>When
 the source resource is not a collection the result of the COPY method 
is the creation of a new resource at the destination whose state and 
behavior match that of the source resource as closely as possible. After
 a successful COPY invocation, all properties on the source resource <em class="bcp14">MUST</em>
 be duplicated on the destination resource, subject to modifying headers
 and XML elements, following the definition for copying properties. 
Since the environment at the destination may be different than at the 
source due to factors outside the scope of control of the server, such 
as the absence of resources required for correct operation, it may not 
be possible to completely duplicate the behavior of the resource at the 
destination. Subsequent alterations to the destination resource will not
 modify the source resource. Subsequent alterations to the source 
resource will not modify the destination resource.<a class="self" href="#rfc.section.8.8.1.p.1">¶</a></p></div></section><section id="copy.for.properties"><h4 id="rfc.section.8.8.2"><a href="#rfc.section.8.8.2">8.8.2</a>&nbsp;<a href="#copy.for.properties">COPY for Properties</a></h4><div id="rfc.section.8.8.2.p.1"><p>The following section defines how properties on a resource are handled during a COPY operation.<a class="self" href="#rfc.section.8.8.2.p.1">¶</a></p></div><div id="rfc.section.8.8.2.p.2"><p>Live properties <em class="bcp14">SHOULD</em>
 be duplicated as identically behaving live properties at the 
destination resource. If a property cannot be copied live, then its 
value <em class="bcp14">MUST</em> be duplicated, octet-for-octet, in an 
identically named, dead property on the destination resource subject to 
the effects of the propertybehavior XML element.<a class="self" href="#rfc.section.8.8.2.p.2">¶</a></p></div><div id="rfc.section.8.8.2.p.3"><p>The
 propertybehavior XML element can specify that properties are copied on 
best effort, that all live properties must be successfully copied or the
 method must fail, or that a specified list of live properties must be 
successfully copied or the method must fail. The propertybehavior XML 
element is defined in <a href="#ELEMENT_propertybehaviour" title="propertybehavior XML element">Section&nbsp;12.12</a>.<a class="self" href="#rfc.section.8.8.2.p.3">¶</a></p></div></section><section id="copy.for.collections"><h4 id="rfc.section.8.8.3"><a href="#rfc.section.8.8.3">8.8.3</a>&nbsp;<a href="#copy.for.collections">COPY for Collections</a></h4><div id="rfc.section.8.8.3.p.1"><p>The COPY method on a collection without a Depth header <em class="bcp14">MUST</em>
 act as if a Depth header with value "infinity" was included. A client 
may submit a Depth header on a COPY on a collection with a value of "0" 
or "infinity". DAV compliant servers <em class="bcp14">MUST</em> support the "0" and "infinity" Depth header behaviors.<a class="self" href="#rfc.section.8.8.3.p.1">¶</a></p></div><div id="rfc.section.8.8.3.p.2"><p>A
 COPY of depth infinity instructs that the collection resource 
identified by the Request-URI is to be copied to the location identified
 by the URI in the Destination header, and all its internal member 
resources are to be copied to a location relative to it, recursively 
through all levels of the collection hierarchy.<a class="self" href="#rfc.section.8.8.3.p.2">¶</a></p></div><div id="rfc.section.8.8.3.p.3"><p>A
 COPY of "Depth: 0" only instructs that the collection and its 
properties but not resources identified by its internal member URIs, are
 to be copied.<a class="self" href="#rfc.section.8.8.3.p.3">¶</a></p></div><div id="rfc.section.8.8.3.p.4"><p>Any headers included with a COPY <em class="bcp14">MUST</em> be applied in processing every resource to be copied with the exception of the Destination header.<a class="self" href="#rfc.section.8.8.3.p.4">¶</a></p></div><div id="rfc.section.8.8.3.p.5"><p>The
 Destination header only specifies the destination URI for the 
Request-URI. When applied to members of the collection identified by the
 Request-URI the value of Destination is to be modified to reflect the 
current location in the hierarchy. So, if the Request- URI is /a/ with 
Host header value http://fun.com/ and the Destination is 
http://fun.com/b/ then when http://fun.com/a/c/d is processed it must 
use a Destination of http://fun.com/b/c/d.<a class="self" href="#rfc.section.8.8.3.p.5">¶</a></p></div><div id="rfc.section.8.8.3.p.6"><p>When the COPY method has completed processing it <em class="bcp14">MUST</em> have created a consistent namespace at the destination (see <a href="#http.url.namespace.model" title="HTTP URL Namespace Model">Section&nbsp;5.1</a> for the definition of namespace consistency). However, if an error occurs while copying an internal collection, the server <em class="bcp14">MUST NOT</em>
 copy any resources identified by members of this collection (i.e., the 
server must skip this subtree), as this would create an inconsistent 
namespace. After detecting an error, the COPY operation <em class="bcp14">SHOULD</em>
 try to finish as much of the original copy operation as possible (i.e.,
 the server should still attempt to copy other subtrees and their 
members, that are not descendents of an error-causing collection). So, 
for example, if an infinite depth copy operation is performed on 
collection /a/, which contains collections /a/b/ and /a/c/, and an error
 occurs copying /a/b/, an attempt should still be made to copy /a/c/. 
Similarly, after encountering an error copying a non-collection resource
 as part of an infinite depth copy, the server <em class="bcp14">SHOULD</em> try to finish as much of the original copy operation as possible.<a class="self" href="#rfc.section.8.8.3.p.6">¶</a></p></div><div id="rfc.section.8.8.3.p.7"><p>If
 an error in executing the COPY method occurs with a resource other than
 the resource identified in the Request-URI then the response <em class="bcp14">MUST</em> be a 207 (Multi-Status).<a class="self" href="#rfc.section.8.8.3.p.7">¶</a></p></div><div id="rfc.section.8.8.3.p.8"><p>The 424 (Failed Dependency) status code <em class="bcp14">SHOULD NOT</em>
 be returned in the 207 (Multi-Status) response from a COPY method. 
These responses can be safely omitted because the client will know that 
the progeny of a resource could not be copied when the client receives 
an error for the parent. Additionally 201 (Created)/204 (No Content) 
status codes <em class="bcp14">SHOULD NOT</em> be returned as values in 
207 (Multi-Status) responses from COPY methods. They, too, can be safely
 omitted because they are the default success codes.<a class="self" href="#rfc.section.8.8.3.p.8">¶</a></p></div></section><section id="n-copy-and-the-overwrite-header"><h4 id="rfc.section.8.8.4"><a href="#rfc.section.8.8.4">8.8.4</a>&nbsp;<a href="#n-copy-and-the-overwrite-header">COPY and the Overwrite Header</a></h4><div id="rfc.section.8.8.4.p.1"><p>If a resource exists at the destination and the Overwrite header is "T" then prior to performing the copy the server <em class="bcp14">MUST</em>
 perform a DELETE with "Depth: infinity" on the destination resource. If
 the Overwrite header is set to "F" then the operation will fail.<a class="self" href="#rfc.section.8.8.4.p.1">¶</a></p></div></section><section id="n-status-codes_2"><h4 id="rfc.section.8.8.5"><a href="#rfc.section.8.8.5">8.8.5</a>&nbsp;<a href="#n-status-codes_2">Status Codes</a></h4><div id="rfc.section.8.8.5.p.1"><p>201 (Created) - The source resource was successfully copied. The copy operation resulted in the creation of a new resource.<a class="self" href="#rfc.section.8.8.5.p.1">¶</a></p></div><div id="rfc.section.8.8.5.p.2"><p>204 (No Content) - The source resource was successfully copied to a pre-existing destination resource.<a class="self" href="#rfc.section.8.8.5.p.2">¶</a></p></div><div id="rfc.section.8.8.5.p.3"><p>403 (Forbidden) - The source and destination URIs are the same.<a class="self" href="#rfc.section.8.8.5.p.3">¶</a></p></div><div id="rfc.section.8.8.5.p.4"><p>409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created.<a class="self" href="#rfc.section.8.8.5.p.4">¶</a></p></div><div id="rfc.section.8.8.5.p.5"><p>412
 (Precondition Failed) - The server was unable to maintain the liveness 
of the properties listed in the propertybehavior XML element or the 
Overwrite header is "F" and the state of the destination resource is 
non-null.<a class="self" href="#rfc.section.8.8.5.p.5">¶</a></p></div><div id="rfc.section.8.8.5.p.6"><p>423 (Locked) - The destination resource was locked.<a class="self" href="#rfc.section.8.8.5.p.6">¶</a></p></div><div id="rfc.section.8.8.5.p.7"><p>502
 (Bad Gateway) - This may occur when the destination is on another 
server and the destination server refuses to accept the resource.<a class="self" href="#rfc.section.8.8.5.p.7">¶</a></p></div><div id="rfc.section.8.8.5.p.8"><p>507
 (Insufficient Storage) - The destination resource does not have 
sufficient space to record the state of the resource after the execution
 of this method.<a class="self" href="#rfc.section.8.8.5.p.8">¶</a></p></div></section><section id="n-example---copy-with-overwrite"><h4 id="rfc.section.8.8.6"><a href="#rfc.section.8.8.6">8.8.6</a>&nbsp;<a href="#n-example---copy-with-overwrite">Example - COPY with Overwrite</a></h4><div id="rfc.section.8.8.6.p.1"><p>This
 example shows resource http://www.ics.uci.edu/~fielding/index.html 
being copied to the location 
http://www.ics.uci.edu/users/f/fielding/index.html. The 204 (No Content)
 status code indicates the existing resource at the destination was 
overwritten.<a class="self" href="#rfc.section.8.8.6.p.1">¶</a></p></div><div id="rfc.figure.u.15"><p>&gt;&gt;Request</p><pre class="text2">   COPY /~fielding/index.html HTTP/1.1
   Host: www.ics.uci.edu
   Destination: http://www.ics.uci.edu/users/f/fielding/index.html
</pre></div><div id="rfc.figure.u.16"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 204 No Content
</pre></div></section><section id="n-example---copy-with-no-overwrite"><h4 id="rfc.section.8.8.7"><a href="#rfc.section.8.8.7">8.8.7</a>&nbsp;<a href="#n-example---copy-with-no-overwrite">Example - COPY with No Overwrite</a></h4><div id="rfc.section.8.8.7.p.1"><p>The
 following example shows the same copy operation being performed, but 
with the Overwrite header set to "F." A response of 412 (Precondition 
Failed) is returned because the destination resource has a non-null 
state.<a class="self" href="#rfc.section.8.8.7.p.1">¶</a></p></div><div id="rfc.figure.u.17"><p>&gt;&gt;Request</p><pre class="text2">   COPY /~fielding/index.html HTTP/1.1
   Host: www.ics.uci.edu
   Destination: http://www.ics.uci.edu/users/f/fielding/index.html
   Overwrite: F
</pre></div><div id="rfc.figure.u.18"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 412 Precondition Failed
</pre></div></section><section id="n-example---copy-of-a-collection"><h4 id="rfc.section.8.8.8"><a href="#rfc.section.8.8.8">8.8.8</a>&nbsp;<a href="#n-example---copy-of-a-collection">Example - COPY of a Collection</a></h4><div id="rfc.figure.u.19"><p>&gt;&gt;Request</p><pre class="text2">   COPY /container/ HTTP/1.1
   Host: www.foo.bar
   Destination: http://www.foo.bar/othercontainer/
   Depth: infinity
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;d:propertybehavior xmlns:d="DAV:"&gt;
     &lt;d:keepalive&gt;*&lt;/d:keepalive&gt;
   &lt;/d:propertybehavior&gt;
</pre></div><div id="rfc.figure.u.20"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;d:multistatus xmlns:d="DAV:"&gt;
      &lt;d:response&gt;
          &lt;d:href&gt;http://www.foo.bar/othercontainer/R2/&lt;/d:href&gt;
          &lt;d:status&gt;HTTP/1.1 412 Precondition Failed&lt;/d:status&gt;
      &lt;/d:response&gt;
   &lt;/d:multistatus&gt;
</pre></div><div id="rfc.section.8.8.8.p.1"><p>The Depth header is 
unnecessary as the default behavior of COPY on a collection is to act as
 if a "Depth: infinity" header had been submitted. In this example most 
of the resources, along with the collection, were copied successfully. 
However the collection R2 failed, most likely due to a problem with 
maintaining the liveness of properties (this is specified by the 
propertybehavior XML element). Because there was an error copying R2, 
none of R2's members were copied. However no errors were listed for 
those members due to the error minimization rules given in <a href="#copy.for.collections" title="COPY for Collections">Section&nbsp;8.8.3</a>.<a class="self" href="#rfc.section.8.8.8.p.1">¶</a></p></div></section></section><section id="METHOD_MOVE"><h3 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a>&nbsp;<a href="#METHOD_MOVE">MOVE Method</a></h3><div id="rfc.section.8.9.p.1"><p>The
 MOVE operation on a non-collection resource is the logical equivalent 
of a copy (COPY), followed by consistency maintenance processing, 
followed by a delete of the source, where all three actions are 
performed atomically. The consistency maintenance step allows the server
 to perform updates caused by the move, such as updating all URIs other 
than the Request-URI which identify the source resource, to point to the
 new destination resource. Consequently, the Destination header <em class="bcp14">MUST</em> be present on all MOVE methods and <em class="bcp14">MUST</em> follow all COPY requirements for the COPY part of the MOVE method. All DAV compliant resources <em class="bcp14">MUST</em>
 support the MOVE method. However, support for the MOVE method does not 
guarantee the ability to move a resource to a particular destination.<a class="self" href="#rfc.section.8.9.p.1">¶</a></p></div><div id="rfc.section.8.9.p.2"><p>For
 example, separate programs may actually control different sets of 
resources on the same server. Therefore, it may not be possible to move a
 resource within a namespace that appears to belong to the same server.<a class="self" href="#rfc.section.8.9.p.2">¶</a></p></div><div id="rfc.section.8.9.p.3"><p>If
 a resource exists at the destination, the destination resource will be 
DELETEd as a side-effect of the MOVE operation, subject to the 
restrictions of the Overwrite header.<a class="self" href="#rfc.section.8.9.p.3">¶</a></p></div><section id="n-move-for-properties"><h4 id="rfc.section.8.9.1"><a href="#rfc.section.8.9.1">8.9.1</a>&nbsp;<a href="#n-move-for-properties">MOVE for Properties</a></h4><div id="rfc.section.8.9.1.p.1"><p>The behavior of properties on a MOVE, including the effects of the propertybehavior XML element, <em class="bcp14">MUST</em> be the same as specified in <a href="#copy.for.properties" title="COPY for Properties">Section&nbsp;8.8.2</a>.<a class="self" href="#rfc.section.8.9.1.p.1">¶</a></p></div></section><section id="n-move-for-collections"><h4 id="rfc.section.8.9.2"><a href="#rfc.section.8.9.2">8.9.2</a>&nbsp;<a href="#n-move-for-collections">MOVE for Collections</a></h4><div id="rfc.section.8.9.2.p.1"><p>A
 MOVE with "Depth: infinity" instructs that the collection identified by
 the Request-URI be moved to the URI specified in the Destination 
header, and all resources identified by its internal member URIs are to 
be moved to locations relative to it, recursively through all levels of 
the collection hierarchy.<a class="self" href="#rfc.section.8.9.2.p.1">¶</a></p></div><div id="rfc.section.8.9.2.p.2"><p>The MOVE method on a collection <em class="bcp14">MUST</em> act as if a "Depth: infinity" header was used on it. A client <em class="bcp14">MUST NOT</em> submit a Depth header on a MOVE on a collection with any value but "infinity".<a class="self" href="#rfc.section.8.9.2.p.2">¶</a></p></div><div id="rfc.section.8.9.2.p.3"><p>Any headers included with MOVE <em class="bcp14">MUST</em> be applied in processing every resource to be moved with the exception of the Destination header.<a class="self" href="#rfc.section.8.9.2.p.3">¶</a></p></div><div id="rfc.section.8.9.2.p.4"><p>The behavior of the Destination header is the same as given for COPY on collections.<a class="self" href="#rfc.section.8.9.2.p.4">¶</a></p></div><div id="rfc.section.8.9.2.p.5"><p>When the MOVE method has completed processing it <em class="bcp14">MUST</em> have created a consistent namespace at both the source and destination (see section <a href="#http.url.namespace.model" title="HTTP URL Namespace Model">5.1</a> for the definition of namespace consistency). However, if an error occurs while moving an internal collection, the server <em class="bcp14">MUST NOT</em>
 move any resources identified by members of the failed collection 
(i.e., the server must skip the error-causing subtree), as this would 
create an inconsistent namespace. In this case, after detecting the 
error, the move operation <em class="bcp14">SHOULD</em> try to finish as
 much of the original move as possible (i.e., the server should still 
attempt to move other subtrees and the resources identified by their 
members, that are not descendents of an error-causing collection). So, 
for example, if an infinite depth move is performed on collection /a/, 
which contains collections /a/b/ and /a/c/, and an error occurs moving 
/a/b/, an attempt should still be made to try moving /a/c/. Similarly, 
after encountering an error moving a non-collection resource as part of 
an infinite depth move, the server <em class="bcp14">SHOULD</em> try to finish as much of the original move operation as possible.<a class="self" href="#rfc.section.8.9.2.p.5">¶</a></p></div><div id="rfc.section.8.9.2.p.6"><p>If an error occurs with a resource other than the resource identified in the Request-URI then the response <em class="bcp14">MUST</em> be a 207 (Multi-Status).<a class="self" href="#rfc.section.8.9.2.p.6">¶</a></p></div><div id="rfc.section.8.9.2.p.7"><p>The 424 (Failed Dependency) status code <em class="bcp14">SHOULD NOT</em>
 be returned in the 207 (Multi-Status) response from a MOVE method. 
These errors can be safely omitted because the client will know that the
 progeny of a resource could not be moved when the client receives an 
error for the parent. Additionally 201 (Created)/204 (No Content) 
responses <em class="bcp14">SHOULD</em> NOT be returned as values in 207
 (Multi-Status) responses from a MOVE. These responses can be safely 
omitted because they are the default success codes.<a class="self" href="#rfc.section.8.9.2.p.7">¶</a></p></div></section><section id="n-move-and-the-overwrite-header"><h4 id="rfc.section.8.9.3"><a href="#rfc.section.8.9.3">8.9.3</a>&nbsp;<a href="#n-move-and-the-overwrite-header">MOVE and the Overwrite Header</a></h4><div id="rfc.section.8.9.3.p.1"><p>If a resource exists at the destination and the Overwrite header is "T" then prior to performing the move the server <em class="bcp14">MUST</em>
 perform a DELETE with "Depth: infinity" on the destination resource. If
 the Overwrite header is set to "F" then the operation will fail.<a class="self" href="#rfc.section.8.9.3.p.1">¶</a></p></div></section><section id="n-status-codes_3"><h4 id="rfc.section.8.9.4"><a href="#rfc.section.8.9.4">8.9.4</a>&nbsp;<a href="#n-status-codes_3">Status Codes</a></h4><div id="rfc.section.8.9.4.p.1"><p>201 (Created) - The source resource was successfully moved, and a new resource was created at the destination.<a class="self" href="#rfc.section.8.9.4.p.1">¶</a></p></div><div id="rfc.section.8.9.4.p.2"><p>204 (No Content) - The source resource was successfully moved to a pre-existing destination resource.<a class="self" href="#rfc.section.8.9.4.p.2">¶</a></p></div><div id="rfc.section.8.9.4.p.3"><p>403 (Forbidden) - The source and destination URIs are the same.<a class="self" href="#rfc.section.8.9.4.p.3">¶</a></p></div><div id="rfc.section.8.9.4.p.4"><p>409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created.<a class="self" href="#rfc.section.8.9.4.p.4">¶</a></p></div><div id="rfc.section.8.9.4.p.5"><p>412
 (Precondition Failed) - The server was unable to maintain the liveness 
of the properties listed in the propertybehavior XML element or the 
Overwrite header is "F" and the state of the destination resource is 
non-null.<a class="self" href="#rfc.section.8.9.4.p.5">¶</a></p></div><div id="rfc.section.8.9.4.p.6"><p>423 (Locked) - The source or the destination resource was locked.<a class="self" href="#rfc.section.8.9.4.p.6">¶</a></p></div><div id="rfc.section.8.9.4.p.7"><p>502
 (Bad Gateway) - This may occur when the destination is on another 
server and the destination server refuses to accept the resource.<a class="self" href="#rfc.section.8.9.4.p.7">¶</a></p></div></section><section id="n-example---move-of-a-non-collection"><h4 id="rfc.section.8.9.5"><a href="#rfc.section.8.9.5">8.9.5</a>&nbsp;<a href="#n-example---move-of-a-non-collection">Example - MOVE of a Non-Collection</a></h4><div id="rfc.section.8.9.5.p.1"><p>This
 example shows resource http://www.ics.uci.edu/~fielding/index.html 
being moved to the location 
http://www.ics.uci.edu/users/f/fielding/index.html. The contents of the 
destination resource would have been overwritten if the destination 
resource had been non-null. In this case, since there was nothing at the
 destination resource, the response code is 201 (Created).<a class="self" href="#rfc.section.8.9.5.p.1">¶</a></p></div><div id="rfc.figure.u.21"><p>&gt;&gt;Request</p><pre class="text2">   MOVE /~fielding/index.html HTTP/1.1
   Host: www.ics.uci.edu
   Destination: http://www.ics.uci.edu/users/f/fielding/index.html
</pre></div><div id="rfc.figure.u.22"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 201 Created
   Location: http://www.ics.uci.edu/users/f/fielding/index.html
</pre></div></section><section id="n-example---move-of-a-collection"><h4 id="rfc.section.8.9.6"><a href="#rfc.section.8.9.6">8.9.6</a>&nbsp;<a href="#n-example---move-of-a-collection">Example - MOVE of a Collection</a></h4><div id="rfc.figure.u.23"><p>&gt;&gt;Request</p><pre class="text2">   MOVE /container/ HTTP/1.1
   Host: www.foo.bar
   Destination: http://www.foo.bar/othercontainer/
   Overwrite: F
   If: (&lt;opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4&gt;)
       (&lt;opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77&gt;)
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;d:propertybehavior xmlns:d='DAV:'&gt;
     &lt;d:keepalive&gt;*&lt;/d:keepalive&gt;
   &lt;/d:propertybehavior&gt;
</pre></div><div id="rfc.figure.u.24"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;d:multistatus xmlns:d='DAV:'&gt;
     &lt;d:response&gt;
          &lt;d:href&gt;http://www.foo.bar/othercontainer/C2/&lt;/d:href&gt;
          &lt;d:status&gt;HTTP/1.1 423 Locked&lt;/d:status&gt;
     &lt;/d:response&gt;
   &lt;/d:multistatus&gt;
</pre></div><div id="rfc.section.8.9.6.p.1"><p>In this example the 
client has submitted a number of lock tokens with the request. A lock 
token will need to be submitted for every resource, both source and 
destination, anywhere in the scope of the method, that is locked. In 
this case the proper lock token was not submitted for the destination 
http://www.foo.bar/othercontainer/C2/. This means that the resource 
/container/C2/ could not be moved. Because there was an error copying 
/container/C2/, none of /container/C2's members were copied. However no 
errors were listed for those members due to the error minimization rules
 given in <a href="#copy.for.collections" title="COPY for Collections">Section&nbsp;8.8.3</a>.
 User agent authentication has previously occurred via a mechanism 
outside the scope of the HTTP protocol, in an underlying transport 
layer.<a class="self" href="#rfc.section.8.9.6.p.1">¶</a></p></div></section></section><section id="METHOD_LOCK"><h3 id="rfc.section.8.10"><a href="#rfc.section.8.10">8.10</a>&nbsp;<a href="#METHOD_LOCK">LOCK Method</a></h3><div id="rfc.section.8.10.p.1"><p>The
 following sections describe the LOCK method, which is used to take out a
 lock of any access type. These sections on the LOCK method describe 
only those semantics that are specific to the LOCK method and are 
independent of the access type of the lock being requested.<a class="self" href="#rfc.section.8.10.p.1">¶</a></p></div><div id="rfc.section.8.10.p.2"><p>Any resource which supports the LOCK method <em class="bcp14">MUST</em>, at minimum, support the XML request and response formats defined herein.<a class="self" href="#rfc.section.8.10.p.2">¶</a></p></div><section id="n-operation"><h4 id="rfc.section.8.10.1"><a href="#rfc.section.8.10.1">8.10.1</a>&nbsp;<a href="#n-operation">Operation</a></h4><div id="rfc.section.8.10.1.p.1"><p>A LOCK method invocation creates the lock specified by the lockinfo XML element on the Request-URI. Lock method requests <em class="bcp14">SHOULD</em>
 have a XML request body which contains an owner XML element for this 
lock request, unless this is a refresh request. The LOCK request may 
have a Timeout header.<a class="self" href="#rfc.section.8.10.1.p.1">¶</a></p></div><div id="rfc.section.8.10.1.p.2"><p>Clients <em class="bcp14">MUST</em>
 assume that locks may arbitrarily disappear at any time, regardless of 
the value given in the Timeout header. The Timeout header only indicates
 the behavior of the server if "extraordinary" circumstances do not 
occur. For example, an administrator may remove a lock at any time or 
the system may crash in such a way that it loses the record of the 
lock's existence. The response <em class="bcp14">MUST</em> contain the value of the lockdiscovery property in a prop XML element.<a class="self" href="#rfc.section.8.10.1.p.2">¶</a></p></div><div id="rfc.section.8.10.1.p.3"><p>In order to indicate the lock token associated with a newly created lock, a Lock-Token response header <em class="bcp14">MUST</em>
 be included in the response for every successful LOCK request for a new
 lock. Note that the Lock-Token header would not be returned in the 
response for a successful refresh LOCK request because a new lock was 
not created.<a class="self" href="#rfc.section.8.10.1.p.3">¶</a></p></div></section><section id="n-the-effect-of-locks-on-properties-and-collections"><h4 id="rfc.section.8.10.2"><a href="#rfc.section.8.10.2">8.10.2</a>&nbsp;<a href="#n-the-effect-of-locks-on-properties-and-collections">The Effect of Locks on Properties and Collections</a></h4><div id="rfc.section.8.10.2.p.1"><p>The
 scope of a lock is the entire state of the resource, including its body
 and associated properties. As a result, a lock on a resource <em class="bcp14">MUST</em> also lock the resource's properties.<a class="self" href="#rfc.section.8.10.2.p.1">¶</a></p></div><div id="rfc.section.8.10.2.p.2"><p>For
 collections, a lock also affects the ability to add or remove members. 
The nature of the effect depends upon the type of access control 
involved.<a class="self" href="#rfc.section.8.10.2.p.2">¶</a></p></div></section><section id="n-locking-replicated-resources"><h4 id="rfc.section.8.10.3"><a href="#rfc.section.8.10.3">8.10.3</a>&nbsp;<a href="#n-locking-replicated-resources">Locking Replicated Resources</a></h4><div id="rfc.section.8.10.3.p.1"><p>A
 resource may be made available through more than one URI. However locks
 apply to resources, not URIs. Therefore a LOCK request on a resource <em class="bcp14">MUST NOT</em> succeed if can not be honored by all the URIs through which the resource is addressable.<a class="self" href="#rfc.section.8.10.3.p.1">¶</a></p></div></section><section id="n-depth-and-locking"><h4 id="rfc.section.8.10.4"><a href="#rfc.section.8.10.4">8.10.4</a>&nbsp;<a href="#n-depth-and-locking">Depth and Locking</a></h4><div id="rfc.section.8.10.4.p.1"><p>The Depth header may be used with the LOCK method. Values other than 0 or infinity <em class="bcp14">MUST NOT</em> be used with the Depth header on a LOCK method. All resources that support the LOCK method <em class="bcp14">MUST</em> support the Depth header.<a class="self" href="#rfc.section.8.10.4.p.1">¶</a></p></div><div id="rfc.section.8.10.4.p.2"><p>A Depth header of value 0 means to just lock the resource specified by the Request-URI.<a class="self" href="#rfc.section.8.10.4.p.2">¶</a></p></div><div id="rfc.section.8.10.4.p.3"><p>If
 the Depth header is set to infinity then the resource specified in the 
Request-URI along with all its internal members, all the way down the 
hierarchy, are to be locked. A successful result <em class="bcp14">MUST</em>
 return a single lock token which represents all the resources that have
 been locked. If an UNLOCK is successfully executed on this token, all 
associated resources are unlocked. If the lock cannot be granted to all 
resources, a 409 (Conflict) status code <em class="bcp14">MUST</em> be 
returned with a response entity body containing a multistatus XML 
element describing which resource(s) prevented the lock from being 
granted. Hence, partial success is not an option. Either the entire 
hierarchy is locked or no resources are locked.<a class="self" href="#rfc.section.8.10.4.p.3">¶</a></p></div><div id="rfc.section.8.10.4.p.4"><p>If no Depth header is submitted on a LOCK request then the request <em class="bcp14">MUST</em> act as if a "Depth:infinity" had been submitted.<a class="self" href="#rfc.section.8.10.4.p.4">¶</a></p></div></section><section id="n-interaction-with-other-methods"><h4 id="rfc.section.8.10.5"><a href="#rfc.section.8.10.5">8.10.5</a>&nbsp;<a href="#n-interaction-with-other-methods">Interaction with other Methods</a></h4><div id="rfc.section.8.10.5.p.1"><p>The
 interaction of a LOCK with various methods is dependent upon the lock 
type. However, independent of lock type, a successful DELETE of a 
resource <em class="bcp14">MUST</em> cause all of its locks to be removed.<a class="self" href="#rfc.section.8.10.5.p.1">¶</a></p></div></section><section id="n-lock-compatibility-table"><h4 id="rfc.section.8.10.6"><a href="#rfc.section.8.10.6">8.10.6</a>&nbsp;<a href="#n-lock-compatibility-table">Lock Compatibility Table</a></h4><div id="rfc.table.u.1" class="tt"><p>The table below describes the behavior that occurs when a lock request is made on a resource.</p><table class="tt full tcenter"><thead><tr><th style="width: 40%;">Current lock state / Lock request</th><th>Shared Lock</th><th>Exclusive Lock</th></tr></thead><tbody><tr><td class="left">None</td><td class="left">True</td><td class="left">True</td></tr><tr><td class="left">Shared Lock</td><td class="left">True</td><td class="left">False</td></tr><tr><td class="left">Exclusive Lock</td><td class="left">False</td><td class="left">False*</td></tr></tbody></table><p>Legend: True = lock may be granted. False = lock <em class="bcp14">MUST NOT</em> be granted. *=It is illegal for a principal to request the same lock twice.</p></div><div id="rfc.section.8.10.6.p.1"><p>The
 current lock state of a resource is given in the leftmost column, and 
lock requests are listed in the first row. The intersection of a row and
 column gives the result of a lock request. For example, if a shared 
lock is held on a resource, and an exclusive lock is requested, the 
table entry is "false", indicating the lock must not be granted.<a class="self" href="#rfc.section.8.10.6.p.1">¶</a></p></div></section><section id="n-status-codes_4"><h4 id="rfc.section.8.10.7"><a href="#rfc.section.8.10.7">8.10.7</a>&nbsp;<a href="#n-status-codes_4">Status Codes</a></h4><div id="rfc.section.8.10.7.p.1"><p>200 (OK) - The lock request succeeded and the value of the lockdiscovery property is included in the body.<a class="self" href="#rfc.section.8.10.7.p.1">¶</a></p></div><div id="rfc.section.8.10.7.p.2"><p>412
 (Precondition Failed) - The included lock token was not enforceable on 
this resource or the server could not satisfy the request in the 
lockinfo XML element.<a class="self" href="#rfc.section.8.10.7.p.2">¶</a></p></div><div id="rfc.section.8.10.7.p.3"><p>423 (Locked) - The resource is locked, so the method has been rejected.<a class="self" href="#rfc.section.8.10.7.p.3">¶</a></p></div></section><section id="n-example---simple-lock-request"><h4 id="rfc.section.8.10.8"><a href="#rfc.section.8.10.8">8.10.8</a>&nbsp;<a href="#n-example---simple-lock-request">Example - Simple Lock Request</a></h4><div id="rfc.figure.u.25"><p>&gt;&gt;Request</p><pre class="text2">   LOCK /workspace/webdav/proposal.doc HTTP/1.1
   Host: webdav.sb.aol.com
   Timeout: Infinite, Second-4100000000
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx
   Authorization: Digest username="ejw",
      realm="ejw@webdav.sb.aol.com", nonce="...",
      uri="/workspace/webdav/proposal.doc",
      response="...", opaque="..."

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:lockinfo xmlns:D='DAV:'&gt;
     &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
     &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
     &lt;D:owner&gt;
          &lt;D:href&gt;http://www.ics.uci.edu/~ejw/contact.html&lt;/D:href&gt;
     &lt;/D:owner&gt;
   &lt;/D:lockinfo&gt;
</pre></div><div id="rfc.figure.u.26"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 200 OK
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:prop xmlns:D="DAV:"&gt;
     &lt;D:lockdiscovery&gt;
          &lt;D:activelock&gt;
               &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
               &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
               &lt;D:depth&gt;Infinity&lt;/D:depth&gt;
               &lt;D:owner&gt;
                    &lt;D:href&gt;
                         http://www.ics.uci.edu/~ejw/contact.html
                    &lt;/D:href&gt;
               &lt;/D:owner&gt;
               &lt;D:timeout&gt;Second-604800&lt;/D:timeout&gt;
               &lt;D:locktoken&gt;
                    &lt;D:href&gt;
               opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
                    &lt;/D:href&gt;
               &lt;/D:locktoken&gt;
          &lt;/D:activelock&gt;
     &lt;/D:lockdiscovery&gt;
   &lt;/D:prop&gt;
</pre></div><div id="rfc.section.8.10.8.p.1"><p>This example shows the 
successful creation of an exclusive write lock on resource 
http://webdav.sb.aol.com/workspace/webdav/proposal.doc. The resource 
http://www.ics.uci.edu/~ejw/contact.html contains contact information 
for the owner of the lock. The server has an activity-based timeout 
policy in place on this resource, which causes the lock to automatically
 be removed after 1 week (604800 seconds). Note that the nonce, 
response, and opaque fields have not been calculated in the 
Authorization request header.<a class="self" href="#rfc.section.8.10.8.p.1">¶</a></p></div></section><section id="n-example---refreshing-a-write-lock"><h4 id="rfc.section.8.10.9"><a href="#rfc.section.8.10.9">8.10.9</a>&nbsp;<a href="#n-example---refreshing-a-write-lock">Example - Refreshing a Write Lock</a></h4><div id="rfc.figure.u.27"><p>&gt;&gt;Request</p><pre class="text2">   LOCK /workspace/webdav/proposal.doc HTTP/1.1
   Host: webdav.sb.aol.com
   Timeout: Infinite, Second-4100000000
   If: (&lt;opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4&gt;)
   Authorization: Digest username="ejw",
      realm="ejw@webdav.sb.aol.com", nonce="...",
      uri="/workspace/webdav/proposal.doc",
      response="...", opaque="..."
</pre></div><div id="rfc.figure.u.28"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 200 OK
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:prop xmlns:D="DAV:"&gt;
     &lt;D:lockdiscovery&gt;
          &lt;D:activelock&gt;
               &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
               &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
               &lt;D:depth&gt;Infinity&lt;/D:depth&gt;
               &lt;D:owner&gt;
                    &lt;D:href&gt;
                    http://www.ics.uci.edu/~ejw/contact.html
                    &lt;/D:href&gt;
               &lt;/D:owner&gt;
               &lt;D:timeout&gt;Second-604800&lt;/D:timeout&gt;
               &lt;D:locktoken&gt;
                    &lt;D:href&gt;
               opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
                    &lt;/D:href&gt;
               &lt;/D:locktoken&gt;
          &lt;/D:activelock&gt;
     &lt;/D:lockdiscovery&gt;
   &lt;/D:prop&gt;
</pre></div><div id="rfc.section.8.10.9.p.1"><p>This request would 
refresh the lock, resetting any time outs. Notice that the client asked 
for an infinite time out but the server choose to ignore the request. In
 this example, the nonce, response, and opaque fields have not been 
calculated in the Authorization request header.<a class="self" href="#rfc.section.8.10.9.p.1">¶</a></p></div></section><section id="n-example---multi-resource-lock-request"><h4 id="rfc.section.8.10.10"><a href="#rfc.section.8.10.10">8.10.10</a>&nbsp;<a href="#n-example---multi-resource-lock-request">Example - Multi-Resource Lock Request</a></h4><div id="rfc.figure.u.29"><p>&gt;&gt;Request</p><pre class="text2">   LOCK /webdav/ HTTP/1.1
   Host: webdav.sb.aol.com
   Timeout: Infinite, Second-4100000000
   Depth: infinity
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx
   Authorization: Digest username="ejw",
      realm="ejw@webdav.sb.aol.com", nonce="...",
      uri="/workspace/webdav/proposal.doc",
      response="...", opaque="..."

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:lockinfo xmlns:D="DAV:"&gt;
     &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
     &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
     &lt;D:owner&gt;
          &lt;D:href&gt;http://www.ics.uci.edu/~ejw/contact.html&lt;/D:href&gt;
     &lt;/D:owner&gt;
   &lt;/D:lockinfo&gt;
</pre></div><div id="rfc.figure.u.30"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:multistatus xmlns:D="DAV:"&gt;
     &lt;D:response&gt;
          &lt;D:href&gt;http://webdav.sb.aol.com/webdav/secret&lt;/D:href&gt;
          &lt;D:status&gt;HTTP/1.1 403 Forbidden&lt;/D:status&gt;
     &lt;/D:response&gt;
     &lt;D:response&gt;
          &lt;D:href&gt;http://webdav.sb.aol.com/webdav/&lt;/D:href&gt;
          &lt;D:propstat&gt;
               &lt;D:prop&gt;&lt;D:lockdiscovery/&gt;&lt;/D:prop&gt;
               &lt;D:status&gt;HTTP/1.1 424 Failed Dependency&lt;/D:status&gt;
          &lt;/D:propstat&gt;
     &lt;/D:response&gt;
   &lt;/D:multistatus&gt;
</pre></div><div id="rfc.section.8.10.10.p.1"><p>This example shows a 
request for an exclusive write lock on a collection and all its 
children. In this request, the client has specified that it desires an 
infinite length lock, if available, otherwise a timeout of 4.1 billion 
seconds, if available. The request entity body contains the contact 
information for the principal taking out the lock, in this case a web 
page URL.<a class="self" href="#rfc.section.8.10.10.p.1">¶</a></p></div><div id="rfc.section.8.10.10.p.2"><p>The
 error is a 403 (Forbidden) response on the resource 
http://webdav.sb.aol.com/webdav/secret. Because this resource could not 
be locked, none of the resources were locked. Note also that the 
lockdiscovery property for the Request-URI has been included as 
required. In this example the lockdiscovery property is empty which 
means that there are no outstanding locks on the resource.<a class="self" href="#rfc.section.8.10.10.p.2">¶</a></p></div><div id="rfc.section.8.10.10.p.3"><p>In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.<a class="self" href="#rfc.section.8.10.10.p.3">¶</a></p></div></section></section><section id="METHOD_UNLOCK"><h3 id="rfc.section.8.11"><a href="#rfc.section.8.11">8.11</a>&nbsp;<a href="#METHOD_UNLOCK">UNLOCK Method</a></h3><div id="rfc.section.8.11.p.1"><p>The
 UNLOCK method removes the lock identified by the lock token in the 
Lock-Token request header from the Request-URI, and all other resources 
included in the lock. If all resources which have been locked under the 
submitted lock token can not be unlocked then the UNLOCK request <em class="bcp14">MUST</em> fail.<a class="self" href="#rfc.section.8.11.p.1">¶</a></p></div><div id="rfc.section.8.11.p.2"><p>Any DAV compliant resource which supports the LOCK method <em class="bcp14">MUST</em> support the UNLOCK method.<a class="self" href="#rfc.section.8.11.p.2">¶</a></p></div><section id="n-example---unlock"><h4 id="rfc.section.8.11.1"><a href="#rfc.section.8.11.1">8.11.1</a>&nbsp;<a href="#n-example---unlock">Example - UNLOCK</a></h4><div id="rfc.figure.u.31"><p>&gt;&gt;Request</p><pre class="text2">   UNLOCK /workspace/webdav/info.doc HTTP/1.1
   Host: webdav.sb.aol.com
   Lock-Token: &lt;opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7&gt;
   Authorization: Digest username="ejw",
      realm="ejw@webdav.sb.aol.com", nonce="...",
      uri="/workspace/webdav/proposal.doc",
      response="...", opaque="..."
</pre></div><div id="rfc.figure.u.32"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 204 No Content
</pre></div><div id="rfc.section.8.11.1.p.1"><p>In this example, the 
lock identified by the lock token 
"opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully 
removed from the resource 
http://webdav.sb.aol.com/workspace/webdav/info.doc. If this lock 
included more than just one resource, the lock is removed from all 
resources included in the lock. The 204 (No Content) status code is used
 instead of 200 (OK) because there is no response entity body.<a class="self" href="#rfc.section.8.11.1.p.1">¶</a></p></div><div id="rfc.section.8.11.1.p.2"><p>In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.<a class="self" href="#rfc.section.8.11.1.p.2">¶</a></p></div></section></section></section><section id="http.headers.for.distributed.authoring"><h2 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a href="#http.headers.for.distributed.authoring">HTTP Headers for Distributed Authoring</a></h2><section id="HEADER_DAV"><h3 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a href="#HEADER_DAV">DAV Header</a></h3><div id="rfc.figure.u.33"><pre class="inline">   DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]
</pre></div><div id="rfc.section.9.1.p.1"><p>This header indicates that the resource supports the DAV schema and protocol as specified. All DAV compliant resources <em class="bcp14">MUST</em> return the DAV header on all OPTIONS responses.<a class="self" href="#rfc.section.9.1.p.1">¶</a></p></div><div id="rfc.section.9.1.p.2"><p>The
 value is a list of all compliance classes that the resource supports. 
Note that above a comma has already been added to the 2. This is because
 a resource can not be level 2 compliant unless it is also level 1 
compliant. Please refer to <a href="#dav.compliance.classes" title="DAV Compliance Classes">Section&nbsp;15</a> for more details. In general, however, support for one compliance class does not entail support for any other.<a class="self" href="#rfc.section.9.1.p.2">¶</a></p></div></section><section id="HEADER_Depth"><h3 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a href="#HEADER_Depth">Depth Header</a></h3><div id="rfc.figure.u.34"><pre class="inline">   Depth = "Depth" ":" ("0" | "1" | "infinity")
</pre></div><div id="rfc.section.9.2.p.1"><p>The Depth header is used 
with methods executed on resources which could potentially have internal
 members to indicate whether the method is to be applied only to the 
resource ("Depth: 0"), to the resource and its immediate children, 
("Depth: 1"), or the resource and all its progeny ("Depth: infinity").<a class="self" href="#rfc.section.9.2.p.1">¶</a></p></div><div id="rfc.section.9.2.p.2"><p>The Depth header is only supported if a method's definition explicitly provides for such support.<a class="self" href="#rfc.section.9.2.p.2">¶</a></p></div><div id="rfc.section.9.2.p.3"><p>The
 following rules are the default behavior for any method that supports 
the Depth header. A method may override these defaults by defining 
different behavior in its definition.<a class="self" href="#rfc.section.9.2.p.3">¶</a></p></div><div id="rfc.section.9.2.p.4"><p>Methods
 which support the Depth header may choose not to support all of the 
header's values and may define, on a case by case basis, the behavior of
 the method if a Depth header is not present. For example, the MOVE 
method only supports "Depth: infinity" and if a Depth header is not 
present will act as if a "Depth: infinity" header had been applied.<a class="self" href="#rfc.section.9.2.p.4">¶</a></p></div><div id="rfc.section.9.2.p.5"><p>Clients <em class="bcp14">MUST NOT</em>
 rely upon methods executing on members of their hierarchies in any 
particular order or on the execution being atomic unless the particular 
method explicitly provides such guarantees.<a class="self" href="#rfc.section.9.2.p.5">¶</a></p></div><div id="rfc.section.9.2.p.6"><p>Upon
 execution, a method with a Depth header will perform as much of its 
assigned task as possible and then return a response specifying what it 
was able to accomplish and what it failed to do.<a class="self" href="#rfc.section.9.2.p.6">¶</a></p></div><div id="rfc.section.9.2.p.7"><p>So, for example, an attempt to COPY a hierarchy may result in some of the members being copied and some not.<a class="self" href="#rfc.section.9.2.p.7">¶</a></p></div><div id="rfc.section.9.2.p.8"><p>Any headers on a method that has a defined interaction with the Depth header <em class="bcp14">MUST</em>
 be applied to all resources in the scope of the method except where 
alternative behavior is explicitly defined. For example, an If-Match 
header will have its value applied against every resource in the 
method's scope and will cause the method to fail if the header fails to 
match.<a class="self" href="#rfc.section.9.2.p.8">¶</a></p></div><div id="rfc.section.9.2.p.9"><p>If
 a resource, source or destination, within the scope of the method with a
 Depth header is locked in such a way as to prevent the successful 
execution of the method, then the lock token for that resource <em class="bcp14">MUST</em> be submitted with the request in the If request header.<a class="self" href="#rfc.section.9.2.p.9">¶</a></p></div><div id="rfc.section.9.2.p.10"><p>The
 Depth header only specifies the behavior of the method with regards to 
internal children. If a resource does not have internal children then 
the Depth header <em class="bcp14">MUST</em> be ignored.<a class="self" href="#rfc.section.9.2.p.10">¶</a></p></div><div id="rfc.section.9.2.p.11"><p>Please
 note, however, that it is always an error to submit a value for the 
Depth header that is not allowed by the method's definition. Thus 
submitting a "Depth: 1" on a COPY, even if the resource does not have 
internal members, will result in a 400 (Bad Request). The method should 
fail not because the resource doesn't have internal members, but because
 of the illegal value in the header.<a class="self" href="#rfc.section.9.2.p.11">¶</a></p></div></section><section id="HEADER_Destination"><h3 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a href="#HEADER_Destination">Destination Header</a></h3><div id="rfc.figure.u.35"><pre class="inline">   Destination = "Destination" ":" absoluteURI
</pre></div><div id="rfc.section.9.3.p.1"><p>The Destination header 
specifies the URI which identifies a destination resource for methods 
such as COPY and MOVE, which take two URIs as parameters. Note that the 
absoluteURI production is defined in <a href="#RFC2396" id="rfc.xref.RFC2396.6"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>.<a class="self" href="#rfc.section.9.3.p.1">¶</a></p></div></section><section id="HEADER_If"><h3 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a href="#HEADER_If">If Header</a></h3><div id="rfc.figure.u.36"><pre class="inline">   If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
   No-tag-list = List
   Tagged-list = Resource 1*List
   Resource = Coded-URL
   List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
   State-token = Coded-URL
   Coded-URL = "&lt;" absoluteURI "&gt;"
</pre></div><div id="rfc.section.9.4.p.1"><p>The If header is intended to have similar functionality to the If-Match header defined in section <a href="https://tools.ietf.org/html/rfc2068#section-14.25" id="rfc.xref.RFC2068.10">14.25</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.11"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
 However the If header is intended for use with any URI which represents
 state information, referred to as a state token, about a resource as 
well as ETags. A typical example of a state token is a lock token, and 
lock tokens are the only state tokens defined in this specification.<a class="self" href="#rfc.section.9.4.p.1">¶</a></p></div><div id="rfc.section.9.4.p.2"><p>All DAV compliant resources <em class="bcp14">MUST</em> honor the If header.<a class="self" href="#rfc.section.9.4.p.2">¶</a></p></div><div id="rfc.section.9.4.p.3"><p>The
 If header's purpose is to describe a series of state lists. If the 
state of the resource to which the header is applied does not match any 
of the specified state lists then the request <em class="bcp14">MUST</em>
 fail with a 412 (Precondition Failed). If one of the described state 
lists matches the state of the resource then the request may succeed.<a class="self" href="#rfc.section.9.4.p.3">¶</a></p></div><div id="rfc.section.9.4.p.4"><p>Note that the absoluteURI production is defined in <a href="#RFC2396" id="rfc.xref.RFC2396.7"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>.<a class="self" href="#rfc.section.9.4.p.4">¶</a></p></div><section id="n-no-tag-list-production"><h4 id="rfc.section.9.4.1"><a href="#rfc.section.9.4.1">9.4.1</a>&nbsp;<a href="#n-no-tag-list-production">No-tag-list Production</a></h4><div id="rfc.section.9.4.1.p.1"><p>The
 No-tag-list production describes a series of state tokens and ETags. If
 multiple No-tag-list productions are used then one only needs to match 
the state of the resource for the method to be allowed to continue.<a class="self" href="#rfc.section.9.4.1.p.1">¶</a></p></div><div id="rfc.section.9.4.1.p.2"><p>If
 a method, due to the presence of a Depth or Destination header, is 
applied to multiple resources then the No-tag-list production <em class="bcp14">MUST</em> be applied to each resource the method is applied to.<a class="self" href="#rfc.section.9.4.1.p.2">¶</a></p></div><section id="n-example---no-tag-list-if-header"><h5 id="rfc.section.9.4.1.1"><a href="#rfc.section.9.4.1.1">9.4.1.1</a>&nbsp;<a href="#n-example---no-tag-list-if-header">Example - No-tag-list If Header</a></h5><div id="rfc.figure.u.37"><pre class="text">   If: (&lt;locktoken:a-write-lock-token&gt; ["I am an ETag"]) (["I am another
   ETag"])
</pre></div><div id="rfc.section.9.4.1.1.p.1"><p>The previous header 
would require that any resources within the scope of the method must 
either be locked with the specified lock token and in the state 
identified by the "I am an ETag" ETag or in the state identified by the 
second ETag "I am another ETag". To put the matter more plainly one can 
think of the previous If header as being in the form (or (and 
&lt;locktoken:a-write-lock-token&gt; ["I am an ETag"]) (and ["I am 
another ETag"])).<a class="self" href="#rfc.section.9.4.1.1.p.1">¶</a></p></div></section></section><section id="n-tagged-list-production"><h4 id="rfc.section.9.4.2"><a href="#rfc.section.9.4.2">9.4.2</a>&nbsp;<a href="#n-tagged-list-production">Tagged-list Production</a></h4><div id="rfc.section.9.4.2.p.1"><p>The
 tagged-list production scopes a list production. That is, it specifies 
that the lists following the resource specification only apply to the 
specified resource. The scope of the resource production begins with the
 list production immediately following the resource production and ends 
with the next resource production, if any.<a class="self" href="#rfc.section.9.4.2.p.1">¶</a></p></div><div id="rfc.section.9.4.2.p.2"><p>When the If header is applied to a particular resource, the Tagged-list productions <em class="bcp14">MUST</em>
 be searched to determine if any of the listed resources match the 
operand resource(s) for the current method. If none of the resource 
productions match the current resource then the header <em class="bcp14">MUST</em>
 be ignored. If one of the resource productions does match the name of 
the resource under consideration then the list productions following the
 resource production <em class="bcp14">MUST</em> be applied to the resource in the manner specified in the previous section.<a class="self" href="#rfc.section.9.4.2.p.2">¶</a></p></div><div id="rfc.section.9.4.2.p.3"><p>The same URI <em class="bcp14">MUST NOT</em> appear more than once in a resource production in an If header.<a class="self" href="#rfc.section.9.4.2.p.3">¶</a></p></div><section id="n-example---tagged-list-if-header"><h5 id="rfc.section.9.4.2.1"><a href="#rfc.section.9.4.2.1">9.4.2.1</a>&nbsp;<a href="#n-example---tagged-list-if-header">Example - Tagged List If header</a></h5><div id="rfc.figure.u.38"><pre class="text2">   COPY /resource1 HTTP/1.1
   Host: www.foo.bar
   Destination: http://www.foo.bar/resource2
   If: &lt;http://www.foo.bar/resource1&gt; (&lt;locktoken:a-write-lock-token&gt;
   [W/"A weak ETag"]) (["strong ETag"])
   &lt;http://www.bar.bar/random&gt;(["another strong ETag"])
</pre></div><div id="rfc.section.9.4.2.1.p.1"><p>In this example 
http://www.foo.bar/resource1 is being copied to 
http://www.foo.bar/resource2. When the method is first applied to 
http://www.foo.bar/resource1, resource1 must be in the state specified 
by "(&lt;locktoken:a-write-lock-token&gt; [W/"A weak ETag"]) (["strong 
ETag"])", that is, it either must be locked with a lock token of 
"locktoken:a-write-lock-token" and have a weak entity tag W/"A weak 
ETag" or it must have a strong entity tag "strong ETag".<a class="self" href="#rfc.section.9.4.2.1.p.1">¶</a></p></div><div id="rfc.section.9.4.2.1.p.2"><p>That
 is the only success condition since the resource 
http://www.bar.bar/random never has the method applied to it (the only 
other resource listed in the If header) and http://www.foo.bar/resource2
 is not listed in the If header.<a class="self" href="#rfc.section.9.4.2.1.p.2">¶</a></p></div></section></section><section id="n-not-production"><h4 id="rfc.section.9.4.3"><a href="#rfc.section.9.4.3">9.4.3</a>&nbsp;<a href="#n-not-production">not Production</a></h4><div id="rfc.section.9.4.3.p.1"><p>Every
 state token or ETag is either current, and hence describes the state of
 a resource, or is not current, and does not describe the state of a 
resource. The boolean operation of matching a state token or ETag to the
 current state of a resource thus resolves to a true or false value. The
 not production is used to reverse that value. The scope of the not 
production is the state-token or entity-tag immediately following it.<a class="self" href="#rfc.section.9.4.3.p.1">¶</a></p></div><div id="rfc.figure.u.39"><pre class="text">   If: (Not &lt;locktoken:write1&gt; &lt;locktoken:write2&gt;)
</pre></div><div id="rfc.section.9.4.3.p.2"><p>When submitted with a 
request, this If header requires that all operand resources must not be 
locked with locktoken:write1 and must be locked with locktoken:write2.<a class="self" href="#rfc.section.9.4.3.p.2">¶</a></p></div></section><section id="n-matching-function"><h4 id="rfc.section.9.4.4"><a href="#rfc.section.9.4.4">9.4.4</a>&nbsp;<a href="#n-matching-function">Matching Function</a></h4><div id="rfc.section.9.4.4.p.1"><p>When performing If header processing, the definition of a matching state token or entity tag is as follows.<a class="self" href="#rfc.section.9.4.4.p.1">¶</a></p></div><div id="rfc.section.9.4.4.p.2"><p>Matching entity tag: Where the entity tag matches an entity tag associated with that resource.<a class="self" href="#rfc.section.9.4.4.p.2">¶</a></p></div><div id="rfc.section.9.4.4.p.3"><p>Matching
 state token: Where there is an exact match between the state token in 
the If header and any state token on the resource.<a class="self" href="#rfc.section.9.4.4.p.3">¶</a></p></div></section><section id="n-if-header-and-non-dav-compliant-proxies"><h4 id="rfc.section.9.4.5"><a href="#rfc.section.9.4.5">9.4.5</a>&nbsp;<a href="#n-if-header-and-non-dav-compliant-proxies">If Header and Non-DAV Compliant Proxies</a></h4><div id="rfc.section.9.4.5.p.1"><p>Non-DAV
 compliant proxies will not honor the If header, since they will not 
understand the If header, and HTTP requires non-understood headers to be
 ignored. When communicating with HTTP/1.1 proxies, the "Cache-Control: 
no-cache" request header <em class="bcp14">MUST</em> be used so as to 
prevent the proxy from improperly trying to service the request from its
 cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache" 
request header <em class="bcp14">MUST</em> be used for the same reason.<a class="self" href="#rfc.section.9.4.5.p.1">¶</a></p></div></section></section><section id="HEADER_Lock-Token"><h3 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a href="#HEADER_Lock-Token">Lock-Token Header</a></h3><div id="rfc.figure.u.40"><pre class="inline">   Lock-Token = "Lock-Token" ":" Coded-URL
</pre></div><div id="rfc.section.9.5.p.1"><p>The Lock-Token request 
header is used with the UNLOCK method to identify the lock to be 
removed. The lock token in the Lock-Token request header <em class="bcp14">MUST</em> identify a lock that contains the resource identified by Request-URI as a member.<a class="self" href="#rfc.section.9.5.p.1">¶</a></p></div><div id="rfc.section.9.5.p.2"><p>The
 Lock-Token response header is used with the LOCK method to indicate the
 lock token created as a result of a successful LOCK request to create a
 new lock.<a class="self" href="#rfc.section.9.5.p.2">¶</a></p></div></section><section id="HEADER_Overwrite"><h3 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a href="#HEADER_Overwrite">Overwrite Header</a></h3><div id="rfc.figure.u.41"><pre class="inline">   Overwrite = "Overwrite" ":" ("T" | "F")
</pre></div><div id="rfc.section.9.6.p.1"><p>The Overwrite header 
specifies whether the server should overwrite the state of a non-null 
destination resource during a COPY or MOVE. A value of "F" states that 
the server must not perform the COPY or MOVE operation if the state of 
the destination resource is non-null. If the overwrite header is not 
included in a COPY or MOVE request then the resource <em class="bcp14">MUST</em>
 treat the request as if it has an overwrite header of value "T". While 
the Overwrite header appears to duplicate the functionality of the 
If-Match: * header of HTTP/1.1, If-Match applies only to the 
Request-URI, and not to the Destination of a COPY or MOVE.<a class="self" href="#rfc.section.9.6.p.1">¶</a></p></div><div id="rfc.section.9.6.p.2"><p>If a COPY or MOVE is not performed due to the value of the Overwrite header, the method <em class="bcp14">MUST</em> fail with a 412 (Precondition Failed) status code.<a class="self" href="#rfc.section.9.6.p.2">¶</a></p></div><div id="rfc.section.9.6.p.3"><p>All DAV compliant resources <em class="bcp14">MUST</em> support the Overwrite header.<a class="self" href="#rfc.section.9.6.p.3">¶</a></p></div></section><section id="HEADER_Status-URI"><h3 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a href="#HEADER_Status-URI">Status-URI Response Header</a></h3><div id="rfc.section.9.7.p.1"><p>The
 Status-URI response header may be used with the 102 (Processing) status
 code to inform the client as to the status of a method.<a class="self" href="#rfc.section.9.7.p.1">¶</a></p></div><div id="rfc.figure.u.42"><pre class="inline">   Status-URI = "Status-URI" ":" *(Status-Code Coded-URL) ; Status-Code
   is defined in <a href="https://tools.ietf.org/html/rfc2068#section-6.1.1" id="rfc.xref.RFC2068.12">Section 6.1.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.13"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>
</pre></div><div id="rfc.section.9.7.p.2"><p>The URIs listed in the 
header are source resources which have been affected by the outstanding 
method. The status code indicates the resolution of the method on the 
identified resource. So, for example, if a MOVE method on a collection 
is outstanding and a 102 (Processing) response with a Status-URI 
response header is returned, the included URIs will indicate resources 
that have had move attempted on them and what the result was.<a class="self" href="#rfc.section.9.7.p.2">¶</a></p></div></section><section id="HEADER_Timeout"><h3 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a href="#HEADER_Timeout">Timeout Request Header</a></h3><div id="rfc.figure.u.43"><pre class="inline">   TimeOut = "Timeout" ":" 1#TimeType
   TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
   DAVTimeOutVal = 1*digit
   Other = "Extend" field-value   ; See section <a href="https://tools.ietf.org/html/rfc2068#section-4.2" id="rfc.xref.RFC2068.14">4.2</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.15"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>
</pre></div><div id="rfc.section.9.8.p.1"><p>Clients may include Timeout
 headers in their LOCK requests. However, the server is not required to 
honor or even consider these requests. Clients <em class="bcp14">MUST NOT</em> submit a Timeout request header with any method other than a LOCK method.<a class="self" href="#rfc.section.9.8.p.1">¶</a></p></div><div id="rfc.section.9.8.p.2"><p>A Timeout request header <em class="bcp14">MUST</em>
 contain at least one TimeType and may contain multiple TimeType 
entries. The purpose of listing multiple TimeType entries is to indicate
 multiple different values and value types that are acceptable to the 
client. The client lists the TimeType entries in order of preference.<a class="self" href="#rfc.section.9.8.p.2">¶</a></p></div><div id="rfc.section.9.8.p.3"><p>Timeout response values <em class="bcp14">MUST</em>
 use a Second value, Infinite, or a TimeType the client has indicated 
familiarity with. The server may assume a client is familiar with any 
TimeType submitted in a Timeout header.<a class="self" href="#rfc.section.9.8.p.3">¶</a></p></div><div id="rfc.section.9.8.p.4"><p>The
 "Second" TimeType specifies the number of seconds that will elapse 
between granting of the lock at the server, and the automatic removal of
 the lock. The timeout value for TimeType "Second" <em class="bcp14">MUST</em> NOT be greater than 2^32-1.<a class="self" href="#rfc.section.9.8.p.4">¶</a></p></div><div id="rfc.section.9.8.p.5"><p>The timeout counter <em class="bcp14">SHOULD</em>
 be restarted any time an owner of the lock sends a method to any member
 of the lock, including unsupported methods, or methods which are 
unsuccessful. However the lock <em class="bcp14">MUST</em> be refreshed if a refresh LOCK method is successfully received.<a class="self" href="#rfc.section.9.8.p.5">¶</a></p></div><div id="rfc.section.9.8.p.6"><p>If
 the timeout expires then the lock may be lost. Specifically, if the 
server wishes to harvest the lock upon time-out, the server <em class="bcp14">SHOULD</em>
 act as if an UNLOCK method was executed by the server on the resource 
using the lock token of the timed-out lock, performed with its override 
authority. Thus logs should be updated with the disposition of the lock,
 notifications should be sent, etc., just as they would be for an UNLOCK
 request.<a class="self" href="#rfc.section.9.8.p.6">¶</a></p></div><div id="rfc.section.9.8.p.7"><p>Servers
 are advised to pay close attention to the values submitted by clients, 
as they will be indicative of the type of activity the client intends to
 perform. For example, an applet running in a browser may need to lock a
 resource, but because of the instability of the environment within 
which the applet is running, the applet may be turned off without 
warning. As a result, the applet is likely to ask for a relatively small
 timeout value so that if the applet dies, the lock can be quickly 
harvested. However, a document management system is likely to ask for an
 extremely long timeout because its user may be planning on going 
off-line.<a class="self" href="#rfc.section.9.8.p.7">¶</a></p></div><div id="rfc.section.9.8.p.8"><p>A client <em class="bcp14">MUST NOT</em> assume that just because the time-out has expired the lock has been lost.<a class="self" href="#rfc.section.9.8.p.8">¶</a></p></div></section></section><section id="status.code.extensions.to.http11"><h2 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a href="#status.code.extensions.to.http11">Status Code Extensions to HTTP/1.1</a></h2><div id="rfc.section.10.p.1"><p>The following status codes are added to those defined in HTTP/1.1 <a href="#RFC2068" id="rfc.xref.RFC2068.16"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.<a class="self" href="#rfc.section.10.p.1">¶</a></p></div><section id="STATUS_102"><h3 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<a href="#STATUS_102">102 Processing</a></h3><div id="rfc.section.10.1.p.1"><p>The
 102 (Processing) status code is an interim response used to inform the 
client that the server has accepted the complete request, but has not 
yet completed it. This status code <em class="bcp14">SHOULD</em> only be
 sent when the server has a reasonable expectation that the request will
 take significant time to complete. As guidance, if a method is taking 
longer than 20 seconds (a reasonable, but arbitrary value) to process 
the server <em class="bcp14">SHOULD</em> return a 102 (Processing) response. The server <em class="bcp14">MUST</em> send a final response after the request has been completed.<a class="self" href="#rfc.section.10.1.p.1">¶</a></p></div><div id="rfc.section.10.1.p.2"><p>Methods
 can potentially take a long period of time to process, especially 
methods that support the Depth header. In such cases the client may 
time-out the connection while waiting for a response. To prevent this 
the server may return a 102 (Processing) status code to indicate to the 
client that the server is still processing the method.<a class="self" href="#rfc.section.10.1.p.2">¶</a></p></div></section><section id="STATUS_207"><h3 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a>&nbsp;<a href="#STATUS_207">207 Multi-Status</a></h3><div id="rfc.section.10.2.p.1"><p>The 207 (Multi-Status) status code provides status for multiple independent operations (see <a href="#multi-status.response" title="Multi-Status Response">Section&nbsp;11</a> for more information).<a class="self" href="#rfc.section.10.2.p.1">¶</a></p></div></section><section id="STATUS_422"><h3 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a href="#STATUS_422">422 Unprocessable Entity</a></h3><div id="rfc.section.10.3.p.1"><p>The
 422 (Unprocessable Entity) status code means the server understands the
 content type of the request entity (hence a 415(Unsupported Media Type)
 status code is inappropriate), and the syntax of the request entity is 
correct (thus a 400 (Bad Request) status code is inappropriate) but was 
unable to process the contained instructions. For example, this error 
condition may occur if an XML request body contains well-formed (i.e., 
syntactically correct), but semantically erroneous XML instructions.<a class="self" href="#rfc.section.10.3.p.1">¶</a></p></div></section><section id="STATUS_423"><h3 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a>&nbsp;<a href="#STATUS_423">423 Locked</a></h3><div id="rfc.section.10.4.p.1"><p>The 423 (Locked) status code means the source or destination resource of a method is locked.<a class="self" href="#rfc.section.10.4.p.1">¶</a></p></div></section><section id="STATUS_424"><h3 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a>&nbsp;<a href="#STATUS_424">424 Failed Dependency</a></h3><div id="rfc.section.10.5.p.1"><p>The
 424 (Failed Dependency) status code means that the method could not be 
performed on the resource because the requested action depended on 
another action and that action failed. For example, if a command in a 
PROPPATCH method fails then, at minimum, the rest of the commands will 
also fail with 424 (Failed Dependency).<a class="self" href="#rfc.section.10.5.p.1">¶</a></p></div></section><section id="STATUS_507"><h3 id="rfc.section.10.6"><a href="#rfc.section.10.6">10.6</a>&nbsp;<a href="#STATUS_507">507 Insufficient Storage</a></h3><div id="rfc.section.10.6.p.1"><p>The
 507 (Insufficient Storage) status code means the method could not be 
performed on the resource because the server is unable to store the 
representation needed to successfully complete the request. This 
condition is considered to be temporary. If the request which received 
this status code was the result of a user action, the request <em class="bcp14">MUST NOT</em> be repeated until it is requested by a separate user action.<a class="self" href="#rfc.section.10.6.p.1">¶</a></p></div></section></section><section id="multi-status.response"><h2 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a href="#multi-status.response">Multi-Status Response</a></h2><div id="rfc.section.11.p.1"><p>The
 default 207 (Multi-Status) response body is a text/xml or 
application/xml HTTP entity that contains a single XML element called 
multistatus, which contains a set of XML elements called response which 
contain 200, 300, 400, and 500 series status codes generated during the 
method invocation. 100 series status codes <em class="bcp14">SHOULD NOT</em> be recorded in a response XML element.<a class="self" href="#rfc.section.11.p.1">¶</a></p></div></section><section id="xml.element.definitions"><h2 id="rfc.section.12"><a href="#rfc.section.12">12.</a>&nbsp;<a href="#xml.element.definitions">XML Element Definitions</a></h2><div id="rfc.section.12.p.1"><p>In the section below, the final line of each section gives the element type declaration using the format defined in <a href="#REC-XML" id="rfc.xref.REC-XML.3"><cite title="Extensible Markup Language (XML) 1.0">[REC-XML]</cite></a>.
 The "Value" field, where present, specifies further restrictions on the
 allowable contents of the XML element using BNF (i.e., to further 
restrict the values of a PCDATA element).<a class="self" href="#rfc.section.12.p.1">¶</a></p></div><section id="ELEMENT_activelock"><h3 id="rfc.section.12.1"><a href="#rfc.section.12.1">12.1</a>&nbsp;<a href="#ELEMENT_activelock">activelock XML Element</a></h3><div id="rfc.section.12.1.p.1"><dl><dt>Name:</dt><dd>activelock</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Describes a lock on a resource.</dd></dl></div><div id="rfc.figure.u.44"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_activelock" class="smpl">activelock</a> (<a href="#ELEMENT_lockscope" class="smpl">lockscope</a>, <a href="#ELEMENT_locktype" class="smpl">locktype</a>, <a href="#ELEMENT_depth" class="smpl">depth</a>, <a href="#ELEMENT_owner" class="smpl">owner</a>?, <a href="#ELEMENT_timeout" class="smpl">timeout</a>?,
   <a href="#ELEMENT_locktoken" class="smpl">locktoken</a>?) &gt;
</pre></div><section id="ELEMENT_depth"><h4 id="rfc.section.12.1.1"><a href="#rfc.section.12.1.1">12.1.1</a>&nbsp;<a href="#ELEMENT_depth">depth XML Element</a></h4><div id="rfc.section.12.1.1.p.1"><dl><dt>Name:</dt><dd>depth</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>The value of the Depth header.</dd><dt>Value:</dt><dd>"0" | "1" | "infinity"</dd></dl></div><div id="rfc.figure.u.45"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_depth" class="smpl">depth</a> (#PCDATA) &gt;
</pre></div></section><section id="ELEMENT_locktoken"><h4 id="rfc.section.12.1.2"><a href="#rfc.section.12.1.2">12.1.2</a>&nbsp;<a href="#ELEMENT_locktoken">locktoken XML Element</a></h4><div id="rfc.section.12.1.2.p.1"><dl><dt>Name:</dt><dd>locktoken</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>The lock token associated with a lock.</dd><dt>Description:</dt><dd>The
 href contains one or more opaque lock token URIs which all refer to the
 same lock (i.e., the OpaqueLockToken-URI production in <a href="#opaquelocktoken.lock.token.uri.scheme" title="opaquelocktoken Lock Token URI Scheme">Section&nbsp;6.4</a>).</dd></dl></div><div id="rfc.figure.u.46"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_locktoken" class="smpl">locktoken</a> (<a href="#ELEMENT_href" class="smpl">href</a>+) &gt;
</pre></div></section><section id="ELEMENT_timeout"><h4 id="rfc.section.12.1.3"><a href="#rfc.section.12.1.3">12.1.3</a>&nbsp;<a href="#ELEMENT_timeout">timeout XML Element</a></h4><div id="rfc.section.12.1.3.p.1"><dl><dt>Name:</dt><dd>timeout</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>The timeout associated with a lock</dd><dt>Value:</dt><dd>TimeType ;Defined in <a href="#HEADER_Timeout" title="Timeout Request Header">Section&nbsp;9.8</a></dd></dl></div><div id="rfc.figure.u.47"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_timeout" class="smpl">timeout</a> (#PCDATA) &gt;
</pre></div></section></section><section id="ELEMENT_collection"><h3 id="rfc.section.12.2"><a href="#rfc.section.12.2">12.2</a>&nbsp;<a href="#ELEMENT_collection">collection XML Element</a></h3><div id="rfc.section.12.2.p.1"><dl><dt>Name:</dt><dd>collection</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Identifies the associated resource as a collection. The resourcetype property of a collection resource <em class="bcp14">MUST</em> have this value.</dd></dl></div><div id="rfc.figure.u.48"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_collection" class="smpl">collection</a> EMPTY &gt;
</pre></div></section><section id="ELEMENT_href"><h3 id="rfc.section.12.3"><a href="#rfc.section.12.3">12.3</a>&nbsp;<a href="#ELEMENT_href">href XML Element</a></h3><div id="rfc.section.12.3.p.1"><dl><dt>Name:</dt><dd>href</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Identifies the content of the element as a URI.</dd><dt>Value:</dt><dd>URI ; See section <a href="https://tools.ietf.org/html/rfc2068#section-3.2.1" id="rfc.xref.RFC2068.17">3.2.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.18"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a></dd></dl></div><div id="rfc.figure.u.49"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_href" class="smpl">href</a> (#PCDATA)&gt;
</pre></div></section><section id="ELEMENT_link"><h3 id="rfc.section.12.4"><a href="#rfc.section.12.4">12.4</a>&nbsp;<a href="#ELEMENT_link">link XML Element</a></h3><div id="rfc.section.12.4.p.1"><dl><dt>Name:</dt><dd>link</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Identifies the property as a link and contains the source and destination of that link.</dd><dt>Description:</dt><dd>The
 link XML element is used to provide the sources and destinations of a 
link. The name of the property containing the link XML element provides 
the type of the link. Link is a multi-valued element, so multiple links 
may be used together to indicate multiple links with the same type. The 
values in the href XML elements inside the src and dst XML elements of 
the link XML element <em class="bcp14">MUST NOT</em> be rejected if they point to resources which do not exist.</dd></dl></div><div id="rfc.figure.u.50"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_link" class="smpl">link</a> (<a href="#ELEMENT_src" class="smpl">src</a>+, <a href="#ELEMENT_dst" class="smpl">dst</a>+) &gt;
</pre></div><section id="ELEMENT_dst"><h4 id="rfc.section.12.4.1"><a href="#rfc.section.12.4.1">12.4.1</a>&nbsp;<a href="#ELEMENT_dst">dst XML Element</a></h4><div id="rfc.section.12.4.1.p.1"><dl><dt>Name:</dt><dd>dst</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Indicates the destination of a link</dd><dt>Value:</dt><dd>URI</dd></dl></div><div id="rfc.figure.u.51"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_dst" class="smpl">dst</a> (#PCDATA) &gt;
</pre></div></section><section id="ELEMENT_src"><h4 id="rfc.section.12.4.2"><a href="#rfc.section.12.4.2">12.4.2</a>&nbsp;<a href="#ELEMENT_src">src XML Element</a></h4><div id="rfc.section.12.4.2.p.1"><dl><dt>Name:</dt><dd>src</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Indicates the source of a link.</dd><dt>Value:</dt><dd>URI</dd></dl></div><div id="rfc.figure.u.52"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_src" class="smpl">src</a> (#PCDATA) &gt;
</pre></div></section></section><section id="ELEMENT_lockentry"><h3 id="rfc.section.12.5"><a href="#rfc.section.12.5">12.5</a>&nbsp;<a href="#ELEMENT_lockentry">lockentry XML Element</a></h3><div id="rfc.section.12.5.p.1"><dl><dt>Name:</dt><dd>lockentry</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Defines the types of locks that can be used with the resource.</dd></dl></div><div id="rfc.figure.u.53"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_lockentry" class="smpl">lockentry</a> (<a href="#ELEMENT_lockscope" class="smpl">lockscope</a>, <a href="#ELEMENT_locktype" class="smpl">locktype</a>) &gt;
</pre></div></section><section id="ELEMENT_lockinfo"><h3 id="rfc.section.12.6"><a href="#rfc.section.12.6">12.6</a>&nbsp;<a href="#ELEMENT_lockinfo">lockinfo XML Element</a></h3><div id="rfc.section.12.6.p.1"><dl><dt>Name:</dt><dd>lockinfo</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>The lockinfo XML element is used with a LOCK method to specify the type of lock the client wishes to have created.</dd></dl></div><div id="rfc.figure.u.54"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_lockinfo" class="smpl">lockinfo</a> (<a href="#ELEMENT_lockscope" class="smpl">lockscope</a>, <a href="#ELEMENT_locktype" class="smpl">locktype</a>, <a href="#ELEMENT_owner" class="smpl">owner</a>?) &gt;
</pre></div></section><section id="ELEMENT_lockscope"><h3 id="rfc.section.12.7"><a href="#rfc.section.12.7">12.7</a>&nbsp;<a href="#ELEMENT_lockscope">lockscope XML Element</a></h3><div id="rfc.section.12.7.p.1"><dl><dt>Name:</dt><dd>lockscope</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies whether a lock is an exclusive lock, or a shared lock.</dd></dl></div><div id="rfc.figure.u.55"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_lockscope" class="smpl">lockscope</a> (<a href="#ELEMENT_exclusive" class="smpl">exclusive</a> | <a href="#ELEMENT_shared" class="smpl">shared</a>) &gt;
</pre></div><section id="ELEMENT_exclusive"><h4 id="rfc.section.12.7.1"><a href="#rfc.section.12.7.1">12.7.1</a>&nbsp;<a href="#ELEMENT_exclusive">exclusive XML Element</a></h4><div id="rfc.section.12.7.1.p.1"><dl><dt>Name:</dt><dd>exclusive</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies an exclusive lock</dd></dl></div><div id="rfc.figure.u.56"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_exclusive" class="smpl">exclusive</a> EMPTY &gt;
</pre></div></section><section id="ELEMENT_shared"><h4 id="rfc.section.12.7.2"><a href="#rfc.section.12.7.2">12.7.2</a>&nbsp;<a href="#ELEMENT_shared">shared XML Element</a></h4><div id="rfc.section.12.7.2.p.1"><dl><dt>Name:</dt><dd>shared</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies a shared lock</dd></dl></div><div id="rfc.figure.u.57"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_shared" class="smpl">shared</a> EMPTY &gt;
</pre></div></section></section><section id="ELEMENT_locktype"><h3 id="rfc.section.12.8"><a href="#rfc.section.12.8">12.8</a>&nbsp;<a href="#ELEMENT_locktype">locktype XML Element</a></h3><div id="rfc.section.12.8.p.1"><dl><dt>Name:</dt><dd>locktype</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies the access type of a lock. At present, this specification only defines one lock type, the write lock.</dd></dl></div><div id="rfc.figure.u.58"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_locktype" class="smpl">locktype</a> (<a href="#ELEMENT_write" class="smpl">write</a>) &gt;
</pre></div><section id="ELEMENT_write"><h4 id="rfc.section.12.8.1"><a href="#rfc.section.12.8.1">12.8.1</a>&nbsp;<a href="#ELEMENT_write">write XML Element</a></h4><div id="rfc.section.12.8.1.p.1"><dl><dt>Name:</dt><dd>write</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies a write lock.</dd></dl></div><div id="rfc.figure.u.59"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_write" class="smpl">write</a> EMPTY &gt;
</pre></div></section></section><section id="ELEMENT_multistatus"><h3 id="rfc.section.12.9"><a href="#rfc.section.12.9">12.9</a>&nbsp;<a href="#ELEMENT_multistatus">multistatus XML Element</a></h3><div id="rfc.section.12.9.p.1"><dl><dt>Name:</dt><dd>multistatus</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains multiple response messages.</dd><dt>Description:</dt><dd>The
 responsedescription at the top level is used to provide a general 
message describing the overarching nature of the response. If this value
 is available an application may use it instead of presenting the 
individual response descriptions contained within the responses.</dd></dl></div><div id="rfc.figure.u.60"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_multistatus" class="smpl">multistatus</a> (<a href="#ELEMENT_response" class="smpl">response</a>+, <a href="#ELEMENT_responsedescription" class="smpl">responsedescription</a>?) &gt;
</pre></div><section id="ELEMENT_response"><h4 id="rfc.section.12.9.1"><a href="#rfc.section.12.9.1">12.9.1</a>&nbsp;<a href="#ELEMENT_response">response XML Element</a></h4><div id="rfc.section.12.9.1.p.1"><dl><dt>Name:</dt><dd>response</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Holds a single response describing the effect of a method on resource and/or its properties.</dd><dt>Description:</dt><dd>A particular href <em class="bcp14">MUST NOT</em>
 appear more than once as the child of a response XML element under a 
multistatus XML element. This requirement is necessary in order to keep 
processing costs for a response to linear time. Essentially, this 
prevents having to search in order to group together all the responses 
by href. There are, however, no requirements regarding ordering based on
 href values.</dd></dl></div><div id="rfc.figure.u.61"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_response" class="smpl">response</a> (<a href="#ELEMENT_href" class="smpl">href</a>, ((<a href="#ELEMENT_href" class="smpl">href</a>*, <a href="#ELEMENT_status" class="smpl">status</a>)|(<a href="#ELEMENT_propstat" class="smpl">propstat</a>+)),
   <a href="#ELEMENT_responsedescription" class="smpl">responsedescription</a>?) &gt;
</pre></div><section id="ELEMENT_propstat"><h5 id="rfc.section.12.9.1.1"><a href="#rfc.section.12.9.1.1">12.9.1.1</a>&nbsp;<a href="#ELEMENT_propstat">propstat XML Element</a></h5><div id="rfc.section.12.9.1.1.p.1"><dl><dt>Name:</dt><dd>propstat</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Groups together a prop and status element that is associated with a particular href element.</dd><dt>Description:</dt><dd>The propstat XML element <em class="bcp14">MUST</em> contain one prop XML element and one status XML element. The contents of the prop XML element <em class="bcp14">MUST</em> only list the names of properties to which the result in the status element applies.</dd></dl></div><div id="rfc.figure.u.62"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_propstat" class="smpl">propstat</a> (<a href="#ELEMENT_prop" class="smpl">prop</a>, <a href="#ELEMENT_status" class="smpl">status</a>, <a href="#ELEMENT_responsedescription" class="smpl">responsedescription</a>?) &gt;
</pre></div></section><section id="ELEMENT_status"><h5 id="rfc.section.12.9.1.2"><a href="#rfc.section.12.9.1.2">12.9.1.2</a>&nbsp;<a href="#ELEMENT_status">status XML Element</a></h5><div id="rfc.section.12.9.1.2.p.1"><dl><dt>Name:</dt><dd>status</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Holds a single HTTP status-line</dd><dt>Value:</dt><dd>status-line ;status-line defined in <a href="#RFC2068" id="rfc.xref.RFC2068.19"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a></dd></dl></div><div id="rfc.figure.u.63"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_status" class="smpl">status</a> (#PCDATA) &gt;
</pre></div></section></section><section id="ELEMENT_responsedescription"><h4 id="rfc.section.12.9.2"><a href="#rfc.section.12.9.2">12.9.2</a>&nbsp;<a href="#ELEMENT_responsedescription">responsedescription XML Element</a></h4><div id="rfc.section.12.9.2.p.1"><dl><dt>Name:</dt><dd>responsedescription</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains a message that can be displayed to the user explaining the nature of the response.</dd><dt>Description:</dt><dd>This XML element provides information suitable to be presented to a user.</dd></dl></div><div id="rfc.figure.u.64"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_responsedescription" class="smpl">responsedescription</a> (#PCDATA) &gt;
</pre></div></section></section><section id="ELEMENT_owner"><h3 id="rfc.section.12.10"><a href="#rfc.section.12.10">12.10</a>&nbsp;<a href="#ELEMENT_owner">owner XML Element</a></h3><div id="rfc.section.12.10.p.1"><dl><dt>Name:</dt><dd>owner</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Provides information about the principal taking out a lock.</dd><dt>Description:</dt><dd>The
 owner XML element provides information sufficient for either directly 
contacting a principal (such as a telephone number or Email URI), or for
 discovering the principal (such as the URL of a homepage) who owns a 
lock.</dd></dl></div><div id="rfc.figure.u.65"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_owner" class="smpl">owner</a> ANY&gt;
</pre></div></section><section id="ELEMENT_prop"><h3 id="rfc.section.12.11"><a href="#rfc.section.12.11">12.11</a>&nbsp;<a href="#ELEMENT_prop">prop XML element</a></h3><div id="rfc.section.12.11.p.1"><dl><dt>Name:</dt><dd>prop</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains properties related to a resource.</dd><dt>Description:</dt><dd>The prop XML element is a generic container for properties defined on resources. All elements inside a prop XML element <em class="bcp14">MUST</em> define properties related to the resource. No other elements may be used inside of a prop element.</dd></dl></div><div id="rfc.figure.u.66"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_prop" class="smpl">prop</a> ANY&gt;
</pre></div></section><section id="ELEMENT_propertybehaviour"><h3 id="rfc.section.12.12"><a href="#rfc.section.12.12">12.12</a>&nbsp;<a href="#ELEMENT_propertybehaviour">propertybehavior XML element</a></h3><div id="rfc.section.12.12.p.1"><dl><dt>Name:</dt><dd>propertybehavior</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies how properties are handled during a COPY or MOVE.</dd><dt>Description:</dt><dd>The
 propertybehavior XML element specifies how properties are handled 
during a COPY or MOVE. If this XML element is not included in the 
request body then the server is expected to act as defined by the 
default property handling behavior of the associated method. All WebDAV 
compliant resources <em class="bcp14">MUST</em> support the propertybehavior XML element.</dd></dl></div><div id="rfc.figure.u.67"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_propertybehaviour" class="smpl">propertybehavior</a> (<a href="#ELEMENT_omit" class="smpl">omit</a> | <a href="#ELEMENT_keepalive" class="smpl">keepalive</a>) &gt;
</pre></div><section id="ELEMENT_keepalive"><h4 id="rfc.section.12.12.1"><a href="#rfc.section.12.12.1">12.12.1</a>&nbsp;<a href="#ELEMENT_keepalive">keepalive XML element</a></h4><div id="rfc.section.12.12.1.p.1"><dl><dt>Name:</dt><dd>keepalive</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies requirements for the copying/moving of live properties.</dd><dt>Description:</dt><dd>If a list of URIs is included as the value of keepalive then the named properties <em class="bcp14">MUST</em>
 be "live" after they are copied (moved) to the destination resource of a
 COPY (or MOVE). If the value "*" is given for the keepalive XML 
element, this designates that all live properties on the source resource
 <em class="bcp14">MUST</em> be live on the destination. If the requirements specified by the keepalive element can not be honored then the method <em class="bcp14">MUST</em> fail with a 412 (Precondition Failed). All DAV compliant resources <em class="bcp14">MUST</em> support the keepalive XML element for use with the COPY and MOVE methods.</dd><dt>Value:</dt><dd>"*" ; #PCDATA value can only be "*"</dd></dl></div><div id="rfc.figure.u.68"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_keepalive" class="smpl">keepalive</a> (#PCDATA | <a href="#ELEMENT_href" class="smpl">href</a>+) &gt;
</pre></div></section><section id="ELEMENT_omit"><h4 id="rfc.section.12.12.2"><a href="#rfc.section.12.12.2">12.12.2</a>&nbsp;<a href="#ELEMENT_omit">omit XML element</a></h4><div id="rfc.section.12.12.2.p.1"><dl><dt>Name:</dt><dd>omit</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>The omit XML element instructs the server that it should use best effort to copy properties but a failure to copy a property <em class="bcp14">MUST NOT</em> cause the method to fail.</dd><dt>Description:</dt><dd>The
 default behavior for a COPY or MOVE is to copy/move all properties or 
fail the method. In certain circumstances, such as when a server copies a
 resource over another protocol such as FTP, it may not be possible to 
copy/move the properties associated with the resource. Thus any attempt 
to copy/move over FTP would always have to fail because properties could
 not be moved over, even as dead properties. All DAV compliant resources
 <em class="bcp14">MUST</em> support the omit XML element on COPY/MOVE methods.</dd></dl></div><div id="rfc.figure.u.69"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_omit" class="smpl">omit</a> EMPTY &gt;
</pre></div></section></section><section id="ELEMENT_propertyupdate"><h3 id="rfc.section.12.13"><a href="#rfc.section.12.13">12.13</a>&nbsp;<a href="#ELEMENT_propertyupdate">propertyupdate XML element</a></h3><div id="rfc.section.12.13.p.1"><dl><dt>Name:</dt><dd>propertyupdate</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains a request to alter the properties on a resource.</dd><dt>Description:</dt><dd>This
 XML element is a container for the information required to modify the 
properties on the resource. This XML element is multi-valued.</dd></dl></div><div id="rfc.figure.u.70"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_propertyupdate" class="smpl">propertyupdate</a> (<a href="#ELEMENT_remove" class="smpl">remove</a> | <a href="#ELEMENT_set" class="smpl">set</a>)+ &gt;
</pre></div><section id="ELEMENT_remove"><h4 id="rfc.section.12.13.1"><a href="#rfc.section.12.13.1">12.13.1</a>&nbsp;<a href="#ELEMENT_remove">remove XML element</a></h4><div id="rfc.section.12.13.1.p.1"><dl><dt>Name:</dt><dd>remove</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Lists the DAV properties to be removed from a resource.</dd><dt>Description:</dt><dd>Remove
 instructs that the properties specified in prop should be removed. 
Specifying the removal of a property that does not exist is not an 
error. All the XML elements in a prop XML element inside of a remove XML
 element <em class="bcp14">MUST</em> be empty, as only the names of properties to be removed are required.</dd></dl></div><div id="rfc.figure.u.71"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_remove" class="smpl">remove</a> (<a href="#ELEMENT_prop" class="smpl">prop</a>) &gt;
</pre></div></section><section id="ELEMENT_set"><h4 id="rfc.section.12.13.2"><a href="#rfc.section.12.13.2">12.13.2</a>&nbsp;<a href="#ELEMENT_set">set XML element</a></h4><div id="rfc.section.12.13.2.p.1"><dl><dt>Name:</dt><dd>set</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Lists the DAV property values to be set for a resource.</dd><dt>Description:</dt><dd>The set XML element <em class="bcp14">MUST</em> contain only a prop XML element. The elements contained by the prop XML element inside the set XML element <em class="bcp14">MUST</em>
 specify the name and value of properties that are set on the resource 
identified by Request-URI. If a property already exists then its value 
is replaced. Language tagging information in the property's value (in 
the "xml:lang" attribute, if present) <em class="bcp14">MUST</em> be persistently stored along with the property, and <em class="bcp14">MUST</em> be subsequently retrievable using PROPFIND.</dd></dl></div><div id="rfc.figure.u.72"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_set" class="smpl">set</a> (<a href="#ELEMENT_prop" class="smpl">prop</a>) &gt;
</pre></div></section></section><section id="ELEMENT_propfind"><h3 id="rfc.section.12.14"><a href="#rfc.section.12.14">12.14</a>&nbsp;<a href="#ELEMENT_propfind">propfind XML Element</a></h3><div id="rfc.section.12.14.p.1"><dl><dt>Name:</dt><dd>propfind</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies
 the properties to be returned from a PROPFIND method. Two special 
elements are specified for use with propfind, allprop and propname. If 
prop is used inside propfind it <em class="bcp14">MUST</em> only contain property names, not values.</dd></dl></div><div id="rfc.figure.u.73"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_propfind" class="smpl">propfind</a> (<a href="#ELEMENT_allprop" class="smpl">allprop</a> | <a href="#ELEMENT_propname" class="smpl">propname</a> | <a href="#ELEMENT_prop" class="smpl">prop</a>) &gt;
</pre></div><section id="ELEMENT_allprop"><h4 id="rfc.section.12.14.1"><a href="#rfc.section.12.14.1">12.14.1</a>&nbsp;<a href="#ELEMENT_allprop">allprop XML Element</a></h4><div id="rfc.section.12.14.1.p.1"><dl><dt>Name:</dt><dd>allprop</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>The allprop XML element specifies that all property names and values on the resource are to be returned.</dd></dl></div><div id="rfc.figure.u.74"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_allprop" class="smpl">allprop</a> EMPTY &gt;
</pre></div></section><section id="ELEMENT_propname"><h4 id="rfc.section.12.14.2"><a href="#rfc.section.12.14.2">12.14.2</a>&nbsp;<a href="#ELEMENT_propname">propname XML Element</a></h4><div id="rfc.section.12.14.2.p.1"><dl><dt>Name:</dt><dd>propname</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>The propname XML element specifies that only a list of property names on the resource is to be returned.</dd></dl></div><div id="rfc.figure.u.75"><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_propname" class="smpl">propname</a> EMPTY &gt;
</pre></div></section></section></section><section id="dav.properties"><h2 id="rfc.section.13"><a href="#rfc.section.13">13.</a>&nbsp;<a href="#dav.properties">DAV Properties</a></h2><div id="rfc.section.13.p.1"><p>For
 DAV properties, the name of the property is also the same as the name 
of the XML element that contains its value. In the section below, the 
final line of each section gives the element type declaration using the 
format defined in <a href="#REC-XML" id="rfc.xref.REC-XML.4"><cite title="Extensible Markup Language (XML) 1.0">[REC-XML]</cite></a>.
 The "Value" field, where present, specifies further restrictions on the
 allowable contents of the XML element using BNF (i.e., to further 
restrict the values of a PCDATA element).<a class="self" href="#rfc.section.13.p.1">¶</a></p></div><section id="PROPERTY_creationdate"><h3 id="rfc.section.13.1"><a href="#rfc.section.13.1">13.1</a>&nbsp;<a href="#PROPERTY_creationdate">creationdate Property</a></h3><div id="rfc.section.13.1.p.1"><dl><dt>Name:</dt><dd>creationdate</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Records the time and date the resource was created.</dd><dt>Value:</dt><dd>date-time ; See <a href="#iso.8601.date.and.time.profile" title="Appendix 2 - ISO 8601 Date and Time Profile">Appendix&nbsp;23.2</a></dd><dt>Description:</dt><dd>The
 creationdate property should be defined on all DAV compliant resources.
 If present, it contains a timestamp of the moment when the resource was
 created (i.e., the moment it had non-null state).</dd></dl></div><div id="rfc.figure.u.76"><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_creationdate" class="smpl">creationdate</a> (#PCDATA) &gt;
</pre></div></section><section id="PROPERTY_displayname"><h3 id="rfc.section.13.2"><a href="#rfc.section.13.2">13.2</a>&nbsp;<a href="#PROPERTY_displayname">displayname Property</a></h3><div id="rfc.section.13.2.p.1"><dl><dt>Name:</dt><dd>displayname</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Provides a name for the resource that is suitable for presentation to a user.</dd><dt>Description:</dt><dd>The
 displayname property should be defined on all DAV compliant resources. 
If present, the property contains a description of the resource that is 
suitable for presentation to a user.</dd></dl></div><div id="rfc.figure.u.77"><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_displayname" class="smpl">displayname</a> (#PCDATA) &gt;
</pre></div></section><section id="PROPERTY_getcontentlanguage"><h3 id="rfc.section.13.3"><a href="#rfc.section.13.3">13.3</a>&nbsp;<a href="#PROPERTY_getcontentlanguage">getcontentlanguage Property</a></h3><div id="rfc.section.13.3.p.1"><dl><dt>Name:</dt><dd>getcontentlanguage</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains the Content-Language header returned by a GET without accept headers</dd><dt>Description:</dt><dd>The getcontentlanguage property <em class="bcp14">MUST</em> be defined on any DAV compliant resource that returns the Content-Language header on a GET.</dd><dt>Value:</dt><dd>language-tag ;language-tag is defined in section <a href="https://tools.ietf.org/html/rfc2068#section-14.13" id="rfc.xref.RFC2068.20">14.13</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.21"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a></dd></dl></div><div id="rfc.figure.u.78"><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_getcontentlanguage" class="smpl">getcontentlanguage</a> (#PCDATA) &gt;
</pre></div></section><section id="PROPERTY_getcontentlength"><h3 id="rfc.section.13.4"><a href="#rfc.section.13.4">13.4</a>&nbsp;<a href="#PROPERTY_getcontentlength">getcontentlength Property</a></h3><div id="rfc.section.13.4.p.1"><dl><dt>Name:</dt><dd>getcontentlength</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains the Content-Length header returned by a GET without accept headers.</dd><dt>Description:</dt><dd>The getcontentlength property <em class="bcp14">MUST</em> be defined on any DAV compliant resource that returns the Content-Length header in response to a GET.</dd><dt>Value:</dt><dd>content-length ; see section <a href="https://tools.ietf.org/html/rfc2068#section-14.14" id="rfc.xref.RFC2068.22">14.14</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.23"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a></dd></dl></div><div id="rfc.figure.u.79"><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_getcontentlength" class="smpl">getcontentlength</a> (#PCDATA) &gt;
</pre></div></section><section id="PROPERTY_getcontenttype"><h3 id="rfc.section.13.5"><a href="#rfc.section.13.5">13.5</a>&nbsp;<a href="#PROPERTY_getcontenttype">getcontenttype Property</a></h3><div id="rfc.section.13.5.p.1"><dl><dt>Name:</dt><dd>getcontenttype</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains the Content-Type header returned by a GET without accept headers.</dd><dt>Description:</dt><dd>This getcontenttype property <em class="bcp14">MUST</em> be defined on any DAV compliant resource that returns the Content-Type header in response to a GET.</dd><dt>Value:</dt><dd>media-type ; defined in section <a href="https://tools.ietf.org/html/rfc2068#section-3.7" id="rfc.xref.RFC2068.24">3.7</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.25"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a></dd></dl></div><div id="rfc.figure.u.80"><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_getcontenttype" class="smpl">getcontenttype</a> (#PCDATA) &gt;
</pre></div></section><section id="PROPERTY_getetag"><h3 id="rfc.section.13.6"><a href="#rfc.section.13.6">13.6</a>&nbsp;<a href="#PROPERTY_getetag">getetag Property</a></h3><div id="rfc.section.13.6.p.1"><dl><dt>Name:</dt><dd>getetag</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains the ETag header returned by a GET without accept headers.</dd><dt>Description:</dt><dd>The getetag property <em class="bcp14">MUST</em> be defined on any DAV compliant resource that returns the Etag header.</dd><dt>Value:</dt><dd>entity-tag ; defined in section <a href="https://tools.ietf.org/html/rfc2068#section-3.11" id="rfc.xref.RFC2068.26">3.11</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.27"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a></dd></dl></div><div id="rfc.figure.u.81"><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_getetag" class="smpl">getetag</a> (#PCDATA) &gt;
</pre></div></section><section id="PROPERTY_getlastmodified"><h3 id="rfc.section.13.7"><a href="#rfc.section.13.7">13.7</a>&nbsp;<a href="#PROPERTY_getlastmodified">getlastmodified Property</a></h3><div id="rfc.section.13.7.p.1"><dl><dt>Name:</dt><dd>getlastmodified</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains the Last-Modified header returned by a GET method without accept headers.</dd><dt>Description:</dt><dd>Note
 that the last-modified date on a resource may reflect changes in any 
part of the state of the resource, not necessarily just a change to the 
response to the GET method. For example, a change in a property may 
cause the last-modified date to change. The getlastmodified property <em class="bcp14">MUST</em> be defined on any DAV compliant resource that returns the Last-Modified header in response to a GET.</dd><dt>Value:</dt><dd>HTTP-date ; defined in section <a href="https://tools.ietf.org/html/rfc2068#section-3.3.1" id="rfc.xref.RFC2068.28">3.3.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.29"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a></dd></dl></div><div id="rfc.figure.u.82"><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_getlastmodified" class="smpl">getlastmodified</a> (#PCDATA) &gt;
</pre></div></section><section id="PROPERTY_lockdiscovery"><h3 id="rfc.section.13.8"><a href="#rfc.section.13.8">13.8</a>&nbsp;<a href="#PROPERTY_lockdiscovery">lockdiscovery Property</a></h3><div id="rfc.section.13.8.p.1"><dl><dt>Name:</dt><dd>lockdiscovery</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Describes the active locks on a resource</dd><dt>Description:</dt><dd>The
 lockdiscovery property returns a listing of who has a lock, what type 
of lock he has, the timeout type and the time remaining on the timeout, 
and the associated lock token. The server is free to withhold any or all
 of this information if the requesting principal does not have 
sufficient access rights to see the requested data.</dd></dl></div><div id="rfc.figure.u.83"><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_lockdiscovery" class="smpl">lockdiscovery</a> (<a href="#ELEMENT_activelock" class="smpl">activelock</a>)* &gt;
</pre></div><section id="n-example---retrieving-the-lockdiscovery-property"><h4 id="rfc.section.13.8.1"><a href="#rfc.section.13.8.1">13.8.1</a>&nbsp;<a href="#n-example---retrieving-the-lockdiscovery-property">Example - Retrieving the lockdiscovery Property</a></h4><div id="rfc.figure.u.84"><p>&gt;&gt;Request</p><pre class="text2">   PROPFIND /container/ HTTP/1.1
   Host: www.foo.bar
   Content-Length: xxxx
   Content-Type: text/xml; charset="utf-8"

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:propfind xmlns:D='DAV:'&gt;
     &lt;D:prop&gt;&lt;D:lockdiscovery/&gt;&lt;/D:prop&gt;
   &lt;/D:propfind&gt;
</pre></div><div id="rfc.figure.u.85"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:multistatus xmlns:D='DAV:'&gt;
     &lt;D:response&gt;
          &lt;D:href&gt;http://www.foo.bar/container/&lt;/D:href&gt;
          &lt;D:propstat&gt;
               &lt;D:prop&gt;
                    &lt;D:lockdiscovery&gt;
                         &lt;D:activelock&gt;
                              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
                              &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
                              &lt;D:depth&gt;0&lt;/D:depth&gt;
                              &lt;D:owner&gt;Jane Smith&lt;/D:owner&gt;
                              &lt;D:timeout&gt;Infinite&lt;/D:timeout&gt;
                              &lt;D:locktoken&gt;
                                   &lt;D:href&gt;
               opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
                                   &lt;/D:href&gt;
                              &lt;/D:locktoken&gt;
                         &lt;/D:activelock&gt;
                    &lt;/D:lockdiscovery&gt;
               &lt;/D:prop&gt;
               &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt;
          &lt;/D:propstat&gt;
     &lt;/D:response&gt;
   &lt;/D:multistatus&gt;
</pre></div><div id="rfc.section.13.8.1.p.1"><p>This resource has a single exclusive write lock on it, with an infinite timeout.<a class="self" href="#rfc.section.13.8.1.p.1">¶</a></p></div></section></section><section id="PROPERTY_resourcetype"><h3 id="rfc.section.13.9"><a href="#rfc.section.13.9">13.9</a>&nbsp;<a href="#PROPERTY_resourcetype">resourcetype Property</a></h3><div id="rfc.section.13.9.p.1"><dl><dt>Name:</dt><dd>resourcetype</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies the nature of the resource.</dd><dt>Description:</dt><dd>The resourcetype property <em class="bcp14">MUST</em> be defined on all DAV compliant resources. The default value is empty.</dd></dl></div><div id="rfc.figure.u.86"><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_resourcetype" class="smpl">resourcetype</a> ANY &gt;
</pre></div></section><section id="PROPERTY_source"><h3 id="rfc.section.13.10"><a href="#rfc.section.13.10">13.10</a>&nbsp;<a href="#PROPERTY_source">source Property</a></h3><div id="rfc.section.13.10.p.1"><dl><dt>Name:</dt><dd>source</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>The destination of the source link identifies the resource that contains the unprocessed source of the link's source.</dd><dt>Description:</dt><dd>The
 source of the link (src) is typically the URI of the output resource on
 which the link is defined, and there is typically only one destination 
(dst) of the link, which is the URI where the unprocessed source of the 
resource may be accessed. When more than one link destination exists, 
this specification asserts no policy on ordering.</dd></dl></div><div id="rfc.figure.u.87"><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_source" class="smpl">source</a> (<a href="#ELEMENT_link" class="smpl">link</a>)* &gt;
</pre></div><section id="n-example---a-source-property"><h4 id="rfc.section.13.10.1"><a href="#rfc.section.13.10.1">13.10.1</a>&nbsp;<a href="#n-example---a-source-property">Example - A source Property</a></h4><div id="rfc.figure.u.88"><pre class="text">   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:prop xmlns:D="DAV:" xmlns:F="http://www.foocorp.com/Project/"&gt;
     &lt;D:source&gt;
          &lt;D:link&gt;
               &lt;F:projfiles&gt;Source&lt;/F:projfiles&gt;
               &lt;D:src&gt;http://foo.bar/program&lt;/D:src&gt;
               &lt;D:dst&gt;http://foo.bar/src/main.c&lt;/D:dst&gt;
          &lt;/D:link&gt;
          &lt;D:link&gt;
               &lt;F:projfiles&gt;Library&lt;/F:projfiles&gt;
               &lt;D:src&gt;http://foo.bar/program&lt;/D:src&gt;
               &lt;D:dst&gt;http://foo.bar/src/main.lib&lt;/D:dst&gt;
          &lt;/D:link&gt;
          &lt;D:link&gt;
               &lt;F:projfiles&gt;Makefile&lt;/F:projfiles&gt;
               &lt;D:src&gt;http://foo.bar/program&lt;/D:src&gt;
               &lt;D:dst&gt;http://foo.bar/src/makefile&lt;/D:dst&gt;
          &lt;/D:link&gt;
     &lt;/D:source&gt;
   &lt;/D:prop&gt;
</pre></div><div id="rfc.section.13.10.1.p.1"><p>In this example the 
resource http://foo.bar/program has a source property that contains 
three links. Each link contains three elements, two of which, src and 
dst, are part of the DAV schema defined in this document, and one which 
is defined by the schema http://www.foocorp.com/project/ (Source, 
Library, and Makefile). A client which only implements the elements in 
the DAV spec will not understand the foocorp elements and will ignore 
them, thus seeing the expected source and destination links. An enhanced
 client may know about the foocorp elements and be able to present the 
user with additional information about the links. This example 
demonstrates the power of XML markup, allowing element values to be 
enhanced without breaking older clients.<a class="self" href="#rfc.section.13.10.1.p.1">¶</a></p></div></section></section><section id="PROPERTY_supportedlock"><h3 id="rfc.section.13.11"><a href="#rfc.section.13.11">13.11</a>&nbsp;<a href="#PROPERTY_supportedlock">supportedlock Property</a></h3><div id="rfc.section.13.11.p.1"><dl><dt>Name:</dt><dd>supportedlock</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>To provide a listing of the lock capabilities supported by the resource.</dd><dt>Description:</dt><dd>The
 supportedlock property of a resource returns a listing of the 
combinations of scope and access types which may be specified in a lock 
request on the resource. Note that the actual contents are themselves 
controlled by access controls so a server is not required to provide 
information the client is not authorized to see.</dd></dl></div><div id="rfc.figure.u.89"><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_supportedlock" class="smpl">supportedlock</a> (<a href="#ELEMENT_lockentry" class="smpl">lockentry</a>)* &gt;
</pre></div><section id="n-example---retrieving-the-supportedlock-property"><h4 id="rfc.section.13.11.1"><a href="#rfc.section.13.11.1">13.11.1</a>&nbsp;<a href="#n-example---retrieving-the-supportedlock-property">Example - Retrieving the supportedlock Property</a></h4><div id="rfc.figure.u.90"><p>&gt;&gt;Request</p><pre class="text2">   PROPFIND  /container/ HTTP/1.1
   Host: www.foo.bar
   Content-Length: xxxx
   Content-Type: text/xml; charset="utf-8"

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:propfind xmlns:D="DAV:"&gt;
     &lt;D:prop&gt;&lt;D:supportedlock/&gt;&lt;/D:prop&gt;
   &lt;/D:propfind&gt;
</pre></div><div id="rfc.figure.u.91"><p>&gt;&gt;Response</p><pre class="text">   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:multistatus xmlns:D="DAV:"&gt;
     &lt;D:response&gt;
          &lt;D:href&gt;http://www.foo.bar/container/&lt;/D:href&gt;
          &lt;D:propstat&gt;
               &lt;D:prop&gt;
                    &lt;D:supportedlock&gt;
                         &lt;D:lockentry&gt;
                              &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
                              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
                         &lt;/D:lockentry&gt;
                         &lt;D:lockentry&gt;
                              &lt;D:lockscope&gt;&lt;D:shared/&gt;&lt;/D:lockscope&gt;
                              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
                         &lt;/D:lockentry&gt;
                    &lt;/D:supportedlock&gt;
               &lt;/D:prop&gt;
               &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt;
          &lt;/D:propstat&gt;
     &lt;/D:response&gt;
   &lt;/D:multistatus&gt;
</pre></div></section></section></section><section id="instructions.for.processing.xml.in.dav"><h2 id="rfc.section.14"><a href="#rfc.section.14">14.</a>&nbsp;<a href="#instructions.for.processing.xml.in.dav">Instructions for Processing XML in DAV</a></h2><div id="rfc.section.14.p.1"><p>All DAV compliant resources <em class="bcp14">MUST</em>
 ignore any unknown XML element and all its children encountered while 
processing a DAV method that uses XML as its command language.<a class="self" href="#rfc.section.14.p.1">¶</a></p></div><div id="rfc.section.14.p.2"><p>This restriction also applies to the processing, by clients, of DAV property values where unknown XML elements <em class="bcp14">SHOULD</em> be ignored unless the property's schema declares otherwise.<a class="self" href="#rfc.section.14.p.2">¶</a></p></div><div id="rfc.section.14.p.3"><p>This restriction does not apply to setting dead DAV properties on the server where the server <em class="bcp14">MUST</em> record unknown XML elements.<a class="self" href="#rfc.section.14.p.3">¶</a></p></div><div id="rfc.section.14.p.4"><p>Additionally,
 this restriction does not apply to the use of XML where XML happens to 
be the content type of the entity body, for example, when used as the 
body of a PUT.<a class="self" href="#rfc.section.14.p.4">¶</a></p></div><div id="rfc.section.14.p.5"><p>Since XML can be transported as text/xml or application/xml, a DAV server <em class="bcp14">MUST</em> accept DAV method requests with XML parameters transported as either text/xml or application/xml, and DAV client <em class="bcp14">MUST</em> accept XML responses using either text/xml or application/xml.<a class="self" href="#rfc.section.14.p.5">¶</a></p></div></section><section id="dav.compliance.classes"><h2 id="rfc.section.15"><a href="#rfc.section.15">15.</a>&nbsp;<a href="#dav.compliance.classes">DAV Compliance Classes</a></h2><div id="rfc.section.15.p.1"><p>A
 DAV compliant resource can choose from two classes of compliance. A 
client can discover the compliance classes of a resource by executing 
OPTIONS on the resource, and examining the "DAV" header which is 
returned.<a class="self" href="#rfc.section.15.p.1">¶</a></p></div><div id="rfc.section.15.p.2"><p>Since this document describes extensions to the HTTP/1.1 protocol, minimally all DAV compliant resources, clients, and proxies <em class="bcp14">MUST</em> be compliant with <a href="#RFC2068" id="rfc.xref.RFC2068.30"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.<a class="self" href="#rfc.section.15.p.2">¶</a></p></div><div id="rfc.section.15.p.3"><p>Compliance
 classes are not necessarily sequential. A resource that is class 2 
compliant must also be class 1 compliant; but if additional compliance 
classes are defined later, a resource that is class 1, 2, and 4 
compliant might not be class 3 compliant. Also note that identifiers 
other than numbers may be used as compliance class identifiers.<a class="self" href="#rfc.section.15.p.3">¶</a></p></div><section id="n-class-1"><h3 id="rfc.section.15.1"><a href="#rfc.section.15.1">15.1</a>&nbsp;<a href="#n-class-1">Class 1</a></h3><div id="rfc.section.15.1.p.1"><p>A class 1 compliant resource <em class="bcp14">MUST</em> meet all "MUST" requirements in all sections of this document.<a class="self" href="#rfc.section.15.1.p.1">¶</a></p></div><div id="rfc.section.15.1.p.2"><p>Class 1 compliant resources <em class="bcp14">MUST</em> return, at minimum, the value "1" in the DAV header on all responses to the OPTIONS method.<a class="self" href="#rfc.section.15.1.p.2">¶</a></p></div></section><section id="n-class-2"><h3 id="rfc.section.15.2"><a href="#rfc.section.15.2">15.2</a>&nbsp;<a href="#n-class-2">Class 2</a></h3><div id="rfc.section.15.2.p.1"><p>A class 2 compliant resource <em class="bcp14">MUST</em>
 meet all class 1 requirements and support the LOCK method, the 
supportedlock property, the lockdiscovery property, the Time-Out 
response header and the Lock-Token request header. A class "2" compliant
 resource <em class="bcp14">SHOULD</em> also support the Time-Out request header and the owner XML element.<a class="self" href="#rfc.section.15.2.p.1">¶</a></p></div><div id="rfc.section.15.2.p.2"><p>Class 2 compliant resources <em class="bcp14">MUST</em> return, at minimum, the values "1" and "2" in the DAV header on all responses to the OPTIONS method.<a class="self" href="#rfc.section.15.2.p.2">¶</a></p></div></section></section><section id="internationalization.considerations"><h2 id="rfc.section.16"><a href="#rfc.section.16">16.</a>&nbsp;<a href="#internationalization.considerations">Internationalization Considerations</a></h2><div id="rfc.section.16.p.1"><p>In the realm of internationalization, this specification complies with the IETF Character Set Policy <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>.
 In this specification, human-readable fields can be found either in the
 value of a property, or in an error message returned in a response 
entity body. In both cases, the human-readable content is encoded using 
XML, which has explicit provisions for character set tagging and 
encoding, and requires that XML processors read XML elements encoded, at
 minimum, using the UTF-8 <a href="#UTF-8" id="rfc.xref.UTF-8.1"><cite title="UTF-8, a transformation format of ISO 10646">[UTF-8]</cite></a>
 encoding of the ISO 10646 multilingual plane. XML examples in this 
specification demonstrate use of the charset parameter of the 
Content-Type header, as defined in <a href="#RFC2376" id="rfc.xref.RFC2376.1"><cite title="XML Media Types">[RFC2376]</cite></a>,
 as well as the XML "encoding" attribute, which together provide charset
 identification information for MIME and XML processors.<a class="self" href="#rfc.section.16.p.1">¶</a></p></div><div id="rfc.section.16.p.2"><p>XML
 also provides a language tagging capability for specifying the language
 of the contents of a particular XML element. XML uses either IANA 
registered language tags (see <a href="#RFC1766" id="rfc.xref.RFC1766.1"><cite title="Tags for the Identification of Languages">[RFC1766]</cite></a>) or ISO 639 language tags <a href="#ISO-639" id="rfc.xref.ISO-639.1"><cite title="ISO 639:1988. Code for the representation of names of languages.">[ISO-639]</cite></a> in the "xml:lang" attribute of an XML element to identify the language of its content and attributes.<a class="self" href="#rfc.section.16.p.2">¶</a></p></div><div id="rfc.section.16.p.3"><p>WebDAV applications <em class="bcp14">MUST</em>
 support the character set tagging, character set encoding, and the 
language tagging functionality of the XML specification. Implementors of
 WebDAV applications are strongly encouraged to read "XML Media Types" <a href="#RFC2376" id="rfc.xref.RFC2376.2"><cite title="XML Media Types">[RFC2376]</cite></a>
 for instruction on which MIME media type to use for XML transport, and 
on use of the charset parameter of the Content-Type header.<a class="self" href="#rfc.section.16.p.3">¶</a></p></div><div id="rfc.section.16.p.4"><p>Names
 used within this specification fall into three categories: names of 
protocol elements such as methods and headers, names of XML elements, 
and names of properties. Naming of protocol elements follows the 
precedent of HTTP, using English names encoded in USASCII for methods 
and headers. Since these protocol elements are not visible to users, and
 are in fact simply long token identifiers, they do not need to support 
encoding in multiple character sets. Similarly, though the names of XML 
elements used in this specification are English names encoded in UTF-8, 
these names are not visible to the user, and hence do not need to 
support multiple character set encodings.<a class="self" href="#rfc.section.16.p.4">¶</a></p></div><div id="rfc.section.16.p.5"><p>The
 name of a property defined on a resource is a URI. Although some 
applications (e.g., a generic property viewer) will display property 
URIs directly to their users, it is expected that the typical 
application will use a fixed set of properties, and will provide a 
mapping from the property name URI to a human-readable field when 
displaying the property name to a user. It is only in the case where the
 set of properties is not known ahead of time that an application need 
display a property name URI to a user. We recommend that applications 
provide human-readable property names wherever feasible.<a class="self" href="#rfc.section.16.p.5">¶</a></p></div><div id="rfc.section.16.p.6"><p>For
 error reporting, we follow the convention of HTTP/1.1 status codes, 
including with each status code a short, English description of the code
 (e.g., 423 (Locked)). While the possibility exists that a poorly 
crafted user agent would display this message to a user, 
internationalized applications will ignore this message, and display an 
appropriate message in the user's language and character set.<a class="self" href="#rfc.section.16.p.6">¶</a></p></div><div id="rfc.section.16.p.7"><p>Since
 interoperation of clients and servers does not require locale 
information, this specification does not specify any mechanism for 
transmission of this information.<a class="self" href="#rfc.section.16.p.7">¶</a></p></div></section><section id="security.considerations"><h2 id="rfc.section.17"><a href="#rfc.section.17">17.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h2><div id="rfc.section.17.p.1"><p>This section is provided to detail issues concerning security implications of which WebDAV applications need to be aware.<a class="self" href="#rfc.section.17.p.1">¶</a></p></div><div id="rfc.section.17.p.2"><p>All of the security considerations of HTTP/1.1 (discussed in <a href="#RFC2068" id="rfc.xref.RFC2068.31"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>) and XML (discussed in <a href="#RFC2376" id="rfc.xref.RFC2376.3"><cite title="XML Media Types">[RFC2376]</cite></a>)
 also apply to WebDAV. In addition, the security risks inherent in 
remote authoring require stronger authentication technology, introduce 
several new privacy concerns, and may increase the hazards from poor 
server design. These issues are detailed below.<a class="self" href="#rfc.section.17.p.2">¶</a></p></div><section id="n-authentication-of-clients"><h3 id="rfc.section.17.1"><a href="#rfc.section.17.1">17.1</a>&nbsp;<a href="#n-authentication-of-clients">Authentication of Clients</a></h3><div id="rfc.section.17.1.p.1"><p>Due
 to their emphasis on authoring, WebDAV servers need to use 
authentication technology to protect not just access to a network 
resource, but the integrity of the resource as well. Furthermore, the 
introduction of locking functionality requires support for 
authentication.<a class="self" href="#rfc.section.17.1.p.1">¶</a></p></div><div id="rfc.section.17.1.p.2"><p>A
 password sent in the clear over an insecure channel is an inadequate 
means for protecting the accessibility and integrity of a resource as 
the password may be intercepted. Since Basic authentication for HTTP/1.1
 performs essentially clear text transmission of a password, Basic 
authentication <em class="bcp14">MUST NOT</em> be used to authenticate a WebDAV client to a server unless the connection is secure. Furthermore, a WebDAV server <em class="bcp14">MUST NOT</em>
 send Basic authentication credentials in a WWW-Authenticate header 
unless the connection is secure. Examples of secure connections include a
 Transport Layer Security (TLS) connection employing a strong cipher 
suite with mutual authentication of client and server, or a connection 
over a network which is physically secure, for example, an isolated 
network in a building with restricted access.<a class="self" href="#rfc.section.17.1.p.2">¶</a></p></div><div id="rfc.section.17.1.p.3"><p>WebDAV applications <em class="bcp14">MUST</em> support the Digest authentication scheme <a href="#RFC2069" id="rfc.xref.RFC2069.1"><cite title="An Extension to HTTP : Digest Access Authentication">[RFC2069]</cite></a>.
 Since Digest authentication verifies that both parties to a 
communication know a shared secret, a password, without having to send 
that secret in the clear, Digest authentication avoids the security 
problems inherent in Basic authentication while providing a level of 
authentication which is useful in a wide range of scenarios.<a class="self" href="#rfc.section.17.1.p.3">¶</a></p></div></section><section id="n-denial-of-service"><h3 id="rfc.section.17.2"><a href="#rfc.section.17.2">17.2</a>&nbsp;<a href="#n-denial-of-service">Denial of Service</a></h3><div id="rfc.section.17.2.p.1"><p>Denial
 of service attacks are of special concern to WebDAV servers. WebDAV 
plus HTTP enables denial of service attacks on every part of a system's 
resources.<a class="self" href="#rfc.section.17.2.p.1">¶</a></p></div><div id="rfc.section.17.2.p.2"><p>The underlying storage can be attacked by PUTting extremely large files.<a class="self" href="#rfc.section.17.2.p.2">¶</a></p></div><div id="rfc.section.17.2.p.3"><p>Asking for recursive operations on large collections can attack processing time.<a class="self" href="#rfc.section.17.2.p.3">¶</a></p></div><div id="rfc.section.17.2.p.4"><p>Making multiple pipelined requests on multiple connections can attack network connections.<a class="self" href="#rfc.section.17.2.p.4">¶</a></p></div><div id="rfc.section.17.2.p.5"><p>WebDAV servers need to be aware of the possibility of a denial of service attack at all levels.<a class="self" href="#rfc.section.17.2.p.5">¶</a></p></div></section><section id="n-security-through-obscurity"><h3 id="rfc.section.17.3"><a href="#rfc.section.17.3">17.3</a>&nbsp;<a href="#n-security-through-obscurity">Security through Obscurity</a></h3><div id="rfc.section.17.3.p.1"><p>WebDAV
 provides, through the PROPFIND method, a mechanism for listing the 
member resources of a collection. This greatly diminishes the 
effectiveness of security or privacy techniques that rely only on the 
difficulty of discovering the names of network resources. Users of 
WebDAV servers are encouraged to use access control techniques to 
prevent unwanted access to resources, rather than depending on the 
relative obscurity of their resource names.<a class="self" href="#rfc.section.17.3.p.1">¶</a></p></div></section><section id="n-privacy-issues-connected-to-locks"><h3 id="rfc.section.17.4"><a href="#rfc.section.17.4">17.4</a>&nbsp;<a href="#n-privacy-issues-connected-to-locks">Privacy Issues Connected to Locks</a></h3><div id="rfc.section.17.4.p.1"><p>When
 submitting a lock request a user agent may also submit an owner XML 
field giving contact information for the person taking out the lock (for
 those cases where a person, rather than a robot, is taking out the 
lock). This contact information is stored in a lockdiscovery property on
 the resource, and can be used by other collaborators to begin 
negotiation over access to the resource. However, in many cases this 
contact information can be very private, and should not be widely 
disseminated. Servers <em class="bcp14">SHOULD</em> limit read access to the lockdiscovery property as appropriate. Furthermore, user agents <em class="bcp14">SHOULD</em>
 provide control over whether contact information is sent at all, and if
 contact information is sent, control over exactly what information is 
sent.<a class="self" href="#rfc.section.17.4.p.1">¶</a></p></div></section><section id="n-privacy-issues-connected-to-properties"><h3 id="rfc.section.17.5"><a href="#rfc.section.17.5">17.5</a>&nbsp;<a href="#n-privacy-issues-connected-to-properties">Privacy Issues Connected to Properties</a></h3><div id="rfc.section.17.5.p.1"><p>Since
 property values are typically used to hold information such as the 
author of a document, there is the possibility that privacy concerns 
could arise stemming from widespread access to a resource's property 
data. To reduce the risk of inadvertent release of private information 
via properties, servers are encouraged to develop access control 
mechanisms that separate read access to the resource body and read 
access to the resource's properties. This allows a user to control the 
dissemination of their property data without overly restricting access 
to the resource's contents.<a class="self" href="#rfc.section.17.5.p.1">¶</a></p></div></section><section id="n-reduction-of-security-due-to-source-link"><h3 id="rfc.section.17.6"><a href="#rfc.section.17.6">17.6</a>&nbsp;<a href="#n-reduction-of-security-due-to-source-link">Reduction of Security due to Source Link</a></h3><div id="rfc.section.17.6.p.1"><p>HTTP/1.1
 warns against providing read access to script code because it may 
contain sensitive information. Yet WebDAV, via its source link facility,
 can potentially provide a URI for script resources so they may be 
authored. For HTTP/1.1, a server could reasonably prevent access to 
source resources due to the predominance of read-only access. WebDAV, 
with its emphasis on authoring, encourages read and write access to 
source resources, and provides the source link facility to identify the 
source. This reduces the security benefits of eliminating access to 
source resources. Users and administrators of WebDAV servers should be 
very cautious when allowing remote authoring of scripts, limiting read 
and write access to the source resources to authorized principals.<a class="self" href="#rfc.section.17.6.p.1">¶</a></p></div></section><section id="n-implications-of-xml-external-entities"><h3 id="rfc.section.17.7"><a href="#rfc.section.17.7">17.7</a>&nbsp;<a href="#n-implications-of-xml-external-entities">Implications of XML External Entities</a></h3><div id="rfc.section.17.7.p.1"><p>XML supports a facility known as "external entities", defined in section <a href="http://www.w3.org/TR/1998/REC-xml-19980210#sec-external-ent" id="rfc.xref.REC-XML.5">4.2.2</a> of <a href="#REC-XML" id="rfc.xref.REC-XML.6"><cite title="Extensible Markup Language (XML) 1.0">[REC-XML]</cite></a>,
 which instruct an XML processor to retrieve and perform an inline 
include of XML located at a particular URI. An external XML entity can 
be used to append or modify the document type declaration (DTD) 
associated with an XML document. An external XML entity can also be used
 to include XML within the content of an XML document. For 
non-validating XML, such as the XML used in this specification, 
including an external XML entity is not required by <a href="#REC-XML" id="rfc.xref.REC-XML.7"><cite title="Extensible Markup Language (XML) 1.0">[REC-XML]</cite></a>. However, <a href="#REC-XML" id="rfc.xref.REC-XML.8"><cite title="Extensible Markup Language (XML) 1.0">[REC-XML]</cite></a> does state that an XML processor may, at its discretion, include the external XML entity.<a class="self" href="#rfc.section.17.7.p.1">¶</a></p></div><div id="rfc.section.17.7.p.2"><p>External
 XML entities have no inherent trustworthiness and are subject to all 
the attacks that are endemic to any HTTP GET request. Furthermore, it is
 possible for an external XML entity to modify the DTD, and hence affect
 the final form of an XML document, in the worst case significantly 
modifying its semantics, or exposing the XML processor to the security 
risks discussed in <a href="#RFC2376" id="rfc.xref.RFC2376.4"><cite title="XML Media Types">[RFC2376]</cite></a>. Therefore, implementers must be aware that external XML entities should be treated as untrustworthy.<a class="self" href="#rfc.section.17.7.p.2">¶</a></p></div><div id="rfc.section.17.7.p.3"><p>There
 is also the scalability risk that would accompany a widely deployed 
application which made use of external XML entities. In this situation, 
it is possible that there would be significant numbers of requests for 
one external XML entity, potentially overloading any server which fields
 requests for the resource containing the external XML entity.<a class="self" href="#rfc.section.17.7.p.3">¶</a></p></div></section><section id="risks.connected.with.lock.tokens"><h3 id="rfc.section.17.8"><a href="#rfc.section.17.8">17.8</a>&nbsp;<a href="#risks.connected.with.lock.tokens">Risks Connected with Lock Tokens</a></h3><div id="rfc.section.17.8.p.1"><p>This specification, in <a href="#opaquelocktoken.lock.token.uri.scheme" title="opaquelocktoken Lock Token URI Scheme">Section&nbsp;6.4</a>,
 requires the use of Universal Unique Identifiers (UUIDs) for lock 
tokens, in order to guarantee their uniqueness across space and time. 
UUIDs, as defined in <a href="#ISO-11578" id="rfc.xref.ISO-11578.4"><cite title="ISO/IEC 11578:1996. Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)">[ISO-11578]</cite></a>,
 contain a "node" field which "consists of the IEEE address, usually the
 host address. For systems with multiple IEEE 802 nodes, any available 
node address can be used." Since a WebDAV server will issue many locks 
over its lifetime, the implication is that it will also be publicly 
exposing its IEEE 802 address.<a class="self" href="#rfc.section.17.8.p.1">¶</a></p></div><div id="rfc.section.17.8.p.2" class="avoidbreakafter"><p>There are several risks associated with exposure of IEEE 802 addresses. Using the IEEE 802 address:<a class="self" href="#rfc.section.17.8.p.2">¶</a></p></div><div id="rfc.section.17.8.p.3"><ul><li>It is possible to track the movement of hardware from subnet to subnet.</li><li>It may be possible to identify the manufacturer of the hardware running a WebDAV server.</li><li>It may be possible to determine the number of each type of computer running WebDAV.</li></ul></div><div id="rfc.section.17.8.p.4"><p><a href="#node.field.generation.without.the.ieee.802.address" title="Node Field Generation Without the IEEE 802 Address">Section&nbsp;6.4.1</a>
 of this specification details an alternate mechanism for generating the
 "node" field of a UUID without using an IEEE 802 address, which 
alleviates the risks associated with exposure of IEEE 802 addresses by 
using an alternate source of uniqueness.<a class="self" href="#rfc.section.17.8.p.4">¶</a></p></div></section></section><section id="n-iana-considerations"><h2 id="rfc.section.18"><a href="#rfc.section.18">18.</a>&nbsp;<a href="#n-iana-considerations">IANA Considerations</a></h2><div id="rfc.section.18.p.1"><p>This
 document defines two namespaces, the namespace of property names, and 
the namespace of WebDAV-specific XML elements used within property 
values. URIs are used for both names, for several reasons. Assignment of
 a URI does not require a request to a central naming authority, and 
hence allow WebDAV property names and XML elements to be quickly defined
 by any WebDAV user or application. URIs also provide a unique address 
space, ensuring that the distributed users of WebDAV will not have 
collisions among the property names and XML elements they create.<a class="self" href="#rfc.section.18.p.1">¶</a></p></div><div id="rfc.section.18.p.2"><p>This
 specification defines a distinguished set of property names and XML 
elements that are understood by all WebDAV applications. The property 
names and XML elements in this specification are all derived from the 
base URI DAV: by adding a suffix to this URI, for example, 
DAV:creationdate for the "creationdate" property.<a class="self" href="#rfc.section.18.p.2">¶</a></p></div><div id="rfc.section.18.p.3"><p>This specification also defines a URI scheme for the encoding of lock tokens, the opaquelocktoken URI scheme described in <a href="#opaquelocktoken.lock.token.uri.scheme" title="opaquelocktoken Lock Token URI Scheme">Section&nbsp;6.4</a>.<a class="self" href="#rfc.section.18.p.3">¶</a></p></div><div id="rfc.section.18.p.4"><p>To
 ensure correct interoperation based on this specification, IANA must 
reserve the URI namespaces starting with "DAV:" and with 
"opaquelocktoken:" for use by this specification, its revisions, and 
related WebDAV specifications.<a class="self" href="#rfc.section.18.p.4">¶</a></p></div></section><section id="n-intellectual-property"><h2 id="rfc.section.19"><a href="#rfc.section.19">19.</a>&nbsp;<a href="#n-intellectual-property">Intellectual Property</a></h2><div id="rfc.section.19.p.1"><p>The following notice is copied from RFC 2026 <a href="#RFC2026" id="rfc.xref.RFC2026.1"><cite title="The Internet Standards Process -- Revision 3">[RFC2026]</cite></a>, section <a href="https://tools.ietf.org/html/rfc2026#section-10.4" id="rfc.xref.RFC2026.2">10.4</a>, and describes the position of the IETF concerning intellectual property claims made against this document.<a class="self" href="#rfc.section.19.p.1">¶</a></p></div><div id="rfc.section.19.p.2"><p>The
 IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to pertain 
to the implementation or use other technology described in this document
 or the extent to which any license under such rights might or might not
 be available; neither does it represent that it has made any effort to 
identify any such rights. Information on the IETF's procedures with 
respect to rights in standards-track and standards-related documentation
 can be found in BCP-11. Copies of claims of rights made available for 
publication and any assurances of licenses to be made available, or the 
result of an attempt made to obtain a general license or permission for 
the use of such proprietary rights by implementors or users of this 
specification can be obtained from the IETF Secretariat.<a class="self" href="#rfc.section.19.p.2">¶</a></p></div><div id="rfc.section.19.p.3"><p>The
 IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary rights 
which may cover technology that may be required to practice this 
standard. Please address the information to the IETF Executive Director.<a class="self" href="#rfc.section.19.p.3">¶</a></p></div></section><section id="n-acknowledgements"><h2 id="rfc.section.20"><a href="#rfc.section.20">20.</a>&nbsp;<a href="#n-acknowledgements">Acknowledgements</a></h2><div id="rfc.section.20.p.1"><p>A
 specification such as this thrives on piercing critical review and 
withers from apathetic neglect. The authors gratefully acknowledge the 
contributions of the following people, whose insights were so valuable 
at every stage of our work.<a class="self" href="#rfc.section.20.p.1">¶</a></p></div><div id="rfc.section.20.p.2"><p>Terry
 Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan Babich, 
Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-Lee, Dan 
Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith Dawson, Mark
 Day, Brian Deen, Martin Duerst, David Durand, Lee Farrell, Chuck Fay, 
Wesley Felter, Roy Fielding, Mark Fisher, Alan Freier, George 
Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton, Steve 
Henning, Mead Himelstein, Alex Hopmann, Andre van der Hoek, Ben Laurie, 
Paul Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter,
 Michael Mealling, Keith Moore, Thomas Narten, Henrik Nielsen, Kenji 
Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry 
Sanders, Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar 
Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi, Richard N. Taylor, 
Robert Thau, John Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory 
Woodhouse, and Lauren Wood.<a class="self" href="#rfc.section.20.p.2">¶</a></p></div><div id="rfc.section.20.p.3"><p>Two
 from this list deserve special mention. The contributions by Larry 
Masinter have been invaluable, both in helping the formation of the 
working group and in patiently coaching the authors along the way. In so
 many ways he has set high standards we have toiled to meet. The 
contributions of Judith Slein in clarifying the requirements, and in 
patiently reviewing draft after draft, both improved this specification 
and expanded our minds on document management.<a class="self" href="#rfc.section.20.p.3">¶</a></p></div><div id="rfc.section.20.p.4"><p>We would also like to thank John Turner for developing the XML DTD.<a class="self" href="#rfc.section.20.p.4">¶</a></p></div></section><section id="rfc.references"><h2 id="rfc.section.21"><a href="#rfc.section.21">21.</a> References</h2><section id="rfc.references.1"><h3 id="rfc.section.21.1"><a href="#rfc.section.21.1">21.1</a> Normative References</h3><dl class="reference"><dt id="RFC1766">[RFC1766]</dt><dd><a href="mailto:Harald.T.Alvestrand@uninett.no">Alvestrand, H.</a>, “<a href="https://tools.ietf.org/html/rfc1766">Tags for the Identification of Languages</a>”, RFC&nbsp;1766, March&nbsp;1995.</dd><dt id="RFC2277">[RFC2277]</dt><dd><a href="mailto:Harald.T.Alvestrand@uninett.no">Alvestrand, H.</a>, “<a href="https://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>”, BCP&nbsp;18, RFC&nbsp;2277, January&nbsp;1998.</dd><dt id="RFC2119">[RFC2119]</dt><dd><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.</dd><dt id="RFC2396">[RFC2396]</dt><dd><a href="mailto:timbl@w3.org">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu">Fielding, R.</a>, and <a href="mailto:masinter@parc.xerox.com">L. Masinter</a>, “<a href="https://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC&nbsp;2396, August&nbsp;1998.</dd><dt id="REC-XML">[REC-XML]</dt><dd><a href="mailto:tbray@textuality.com">Bray, T.</a>, <a href="mailto:jeanpa@microsoft.com">Paoli, J.</a>, and <a href="mailto:cmsmcq@uic.edu">C. Sperberg-McQueen</a>, “<a href="http://www.w3.org/TR/1998/REC-xml-19980210">Extensible Markup Language (XML) 1.0</a>”, W3C&nbsp;REC-xml-19980210, February&nbsp;1998, &lt;<a href="http://www.w3.org/TR/1998/REC-xml-19980210">http://www.w3.org/TR/1998/REC-xml-19980210</a>&gt;.</dd><dt id="REC-XML-NAMES">[REC-XML-NAMES]</dt><dd><a href="mailto:tbray@textuality.com">Bray, T.</a>, <a href="mailto:dmh@corp.hp.com">Hollander, D.</a>, and <a href="mailto:andrewl@microsoft.com">A. Layman</a>, “<a href="http://www.w3.org/TR/1999/REC-xml-names-19990114">Namespaces in XML</a>”, W3C&nbsp;REC-xml-names-19990114, January&nbsp;1999, &lt;<a href="http://www.w3.org/TR/1999/REC-xml-names-19990114">http://www.w3.org/TR/1999/REC-xml-names-19990114</a>&gt;.</dd><dt id="RFC2069">[RFC2069]</dt><dd><a href="mailto:john@math.nwu.edu">Franks, J.</a>, <a href="mailto:hallam@w3.org">Hallam-Baker, P.</a>, <a href="mailto:jeff@spyglass.com">Hostetler, J.</a>, <a href="mailto:paulle@microsoft.com">Leach, P.</a>, <a href="mailto:luotonen@netscape.com">Luotonen, A.</a>, <a href="mailto:eric@spyglass.com">Sink, E.</a>, and <a href="mailto:stewart@OpenMarket.com">L. Stewart</a>, “<a href="https://tools.ietf.org/html/rfc2069">An Extension to HTTP : Digest Access Authentication</a>”, RFC&nbsp;2069, January&nbsp;1997.</dd><dt id="RFC2068">[RFC2068]</dt><dd><a href="mailto:fielding@ics.uci.edu">Fielding, R.</a>, <a href="mailto:jg@w3.org">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com">Mogul, J.</a>, <a href="mailto:frystyk@w3.org">Frystyk, H.</a>, and <a href="mailto:timbl@w3.org">T. Berners-Lee</a>, “<a href="https://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2068, January&nbsp;1997.</dd><dt id="ISO-639">[ISO-639]</dt><dd><a href="http://www.iso.ch/">International Organization for Standardization</a>, “ISO 639:1988. Code for the representation of names of languages.”, 1988.</dd><dt id="ISO-8601">[ISO-8601]</dt><dd><a href="http://www.iso.ch/">International Organization for Standardization</a>, “ISO 8601, Data elements and interchange formats-Information interchange--Representation of dates and times”, June&nbsp;1988.</dd><dt id="ISO-11578">[ISO-11578]</dt><dd><a href="http://www.iso.ch/">International Organization for Standardization</a>, “ISO/IEC 11578:1996. Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)”, 1996.</dd><dt id="RFC2141">[RFC2141]</dt><dd><a href="mailto:jayhawk@ds.internic.net">Moats, R.</a>, “<a href="https://tools.ietf.org/html/rfc2141">URN Syntax</a>”, RFC&nbsp;2141, May&nbsp;1997.</dd><dt id="UTF-8">[UTF-8]</dt><dd><a href="mailto:fyergeau@alis.com">Yergeau, F.</a>, “<a href="https://tools.ietf.org/html/rfc2279">UTF-8, a transformation format of ISO 10646</a>”, RFC&nbsp;2279, January&nbsp;1998.</dd></dl></section><section id="rfc.references.2"><h3 id="rfc.section.21.2"><a href="#rfc.section.21.2">21.2</a> Informational References</h3><dl class="reference"><dt id="RFC2026">[RFC2026]</dt><dd><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="https://tools.ietf.org/html/rfc2026">The Internet Standards Process -- Revision 3</a>”, BCP&nbsp;9, RFC&nbsp;2026, October&nbsp;1996.</dd><dt id="RFC1807">[RFC1807]</dt><dd><a href="mailto:rlasher@forsythe.stanford.edu">Lasher, R.</a> and <a href="mailto:Cohen@myri.com">D. Cohen</a>, “<a href="https://tools.ietf.org/html/rfc1807">A Format for Bibliographic Records</a>”, RFC&nbsp;1807, June&nbsp;1995.</dd><dt id="WF">[WF]</dt><dd><a href="mailto:lagoze@cs.cornell.edu">Lagoze, C.</a>, “<a href="http://www.dlib.org/dlib/july96/lagoze/07lagoze.html">The Warwick Framework: A Container Architecture for Diverse Sets of Metadata</a>”, July&nbsp;1996, &lt;<a href="http://www.dlib.org/dlib/july96/lagoze/07lagoze.html">http://www.dlib.org/dlib/july96/lagoze/07lagoze.html</a>&gt;.<br>D-Lib Magazine, July/August 1996.</dd><dt id="USMARC">[USMARC]</dt><dd>Network Development and MARC Standards, Office, Washington DC:
          Cataloging Distribution Service, Library of Congress., “USMARC Format for Bibliographic Data”, 1994.</dd><dt id="REC-PICS">[REC-PICS]</dt><dd><a href="mailto:jmiller@w3.org">Miller, J.</a>, <a href="mailto:timk@spyglass.com">Krauskopf, T.</a>, <a href="mailto:presnick@research.att.com">Resnick, P.</a>, and <a href="mailto:treese@OpenMarket.com">W. Treese</a>, “<a href="http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html">PICS Label Distribution Label Syntax and Communication Protocols, Version 1.1</a>”, W3C&nbsp;REC-PICS-labels-961031, October&nbsp;1996, &lt;<a href="http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html">http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html</a>&gt;.</dd><dt id="RFC2291">[RFC2291]</dt><dd><a href="mailto:slein@wrc.xerox.com">Slein, J.</a>, <a href="mailto:fabio@cs.unibo.it">Vitali, F.</a>, <a href="mailto:ejw@ics.uci.edu">Whitehead, E.</a>, and <a href="mailto:dgd@cs.bu.edu">D. Durand</a>, “<a href="https://tools.ietf.org/html/rfc2291">Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web</a>”, RFC&nbsp;2291, February&nbsp;1998.</dd><dt id="RFC2413">[RFC2413]</dt><dd><a href="mailto:weibel@oclc.org">Weibel, S.</a>, <a href="mailto:jak@ckm.ucsf.edu">Kunze, J.</a>, <a href="mailto:lagoze@cs.cornell.edu">Lagoze, C.</a>, and <a href="mailto:misha.wolf@reuters.com">M. Wolf</a>, “<a href="https://tools.ietf.org/html/rfc2413">Dublin Core Metadata for Resource Discovery</a>”, RFC&nbsp;2413, September&nbsp;1998.</dd><dt id="RFC2376">[RFC2376]</dt><dd><a href="mailto:ejw@ics.uci.edu">Whitehead, E.</a> and <a href="mailto:murata@fxis.fujixerox.co.jp">M. Makoto</a>, “<a href="https://tools.ietf.org/html/rfc2376">XML Media Types</a>”, RFC&nbsp;2376, July&nbsp;1998.</dd></dl></section></section><section id="rfc.authors" class="avoidbreakinside"><h2><a href="#rfc.section.22" id="rfc.section.22">22.</a> <a href="#rfc.authors">Authors' Addresses</a></h2><address><b>Y. Y. Goland</b><br>Microsoft Corporation<br>One Microsoft Way<br>Redmond, WA&nbsp;98052-6399<br>EMail: <a href="mailto:yarong@microsoft.com">yarong@microsoft.com</a></address><address><b>E. J. Whitehead, Jr.</b><br>Dept. Of Information and Computer Science,
      University of California, Irvine<br>Irvine, CA&nbsp;92697-3425<br>EMail: <a href="mailto:ejw@ics.uci.edu">ejw@ics.uci.edu</a></address><address><b>A. Faizi</b><br>Netscape<br>685 East Middlefield Road<br>Mountain View, CA&nbsp;94043<br>EMail: <a href="mailto:asad@netscape.com">asad@netscape.com</a></address><address><b>S. R. Carter</b><br>Novell<br>1555 N. Technology Way<br>M/S ORM F111<br>Orem, UT&nbsp;84097-2399<br>EMail: <a href="mailto:srcarter@novell.com">srcarter@novell.com</a></address><address><b>D. Jensen</b><br>Novell<br>1555 N. Technology Way<br>M/S ORM F111<br>Orem, UT&nbsp;84097-2399<br>EMail: <a href="mailto:dcjensen@novell.com">dcjensen@novell.com</a></address></section><section id="n-appendices"><h2 id="rfc.section.23"><a href="#rfc.section.23">23.</a>&nbsp;<a href="#n-appendices">Appendices</a></h2><section id="n-appendix-1---webdav-document-type-definition"><h3 id="rfc.section.23.1"><a href="#rfc.section.23.1">23.1</a>&nbsp;<a href="#n-appendix-1---webdav-document-type-definition">Appendix 1 - WebDAV Document Type Definition</a></h3><div id="rfc.section.23.1.p.1"><p>This section provides a document type definition, following the rules in <a href="#REC-XML" id="rfc.xref.REC-XML.9"><cite title="Extensible Markup Language (XML) 1.0">[REC-XML]</cite></a>,
 for the XML elements used in the protocol stream and in the values of 
properties. It collects the element definitions given in sections <a href="#xml.element.definitions" title="XML Element Definitions">12</a> and <a href="#dav.properties" title="DAV Properties">13</a>.<a class="self" href="#rfc.section.23.1.p.1">¶</a></p></div><div id="rfc.figure.u.92"><pre class="inline">   &lt;!DOCTYPE webdav-1.0 [

   &lt;!--============ XML Elements from <a href="#xml.element.definitions" title="XML Element Definitions">Section&nbsp;12</a> ==================--&gt;

   &lt;!ELEMENT <a href="#ELEMENT_activelock" class="smpl">activelock</a> (<a href="#ELEMENT_lockscope" class="smpl">lockscope</a>, <a href="#ELEMENT_locktype" class="smpl">locktype</a>, <a href="#ELEMENT_depth" class="smpl">depth</a>, <a href="#ELEMENT_owner" class="smpl">owner</a>?, <a href="#ELEMENT_timeout" class="smpl">timeout</a>?,
   <a href="#ELEMENT_locktoken" class="smpl">locktoken</a>?) &gt;

   &lt;!ELEMENT <a href="#ELEMENT_lockentry" class="smpl">lockentry</a> (<a href="#ELEMENT_lockscope" class="smpl">lockscope</a>, <a href="#ELEMENT_locktype" class="smpl">locktype</a>) &gt;
   &lt;!ELEMENT <a href="#ELEMENT_lockinfo" class="smpl">lockinfo</a> (<a href="#ELEMENT_lockscope" class="smpl">lockscope</a>, <a href="#ELEMENT_locktype" class="smpl">locktype</a>, <a href="#ELEMENT_owner" class="smpl">owner</a>?) &gt;

   &lt;!ELEMENT <a href="#ELEMENT_locktype" class="smpl">locktype</a> (<a href="#ELEMENT_write" class="smpl">write</a>) &gt;
   &lt;!ELEMENT <a href="#ELEMENT_write" class="smpl">write</a> EMPTY &gt;

   &lt;!ELEMENT <a href="#ELEMENT_lockscope" class="smpl">lockscope</a> (<a href="#ELEMENT_exclusive" class="smpl">exclusive</a> | <a href="#ELEMENT_shared" class="smpl">shared</a>) &gt;
   &lt;!ELEMENT <a href="#ELEMENT_exclusive" class="smpl">exclusive</a> EMPTY &gt;
   &lt;!ELEMENT <a href="#ELEMENT_shared" class="smpl">shared</a> EMPTY &gt;

   &lt;!ELEMENT <a href="#ELEMENT_depth" class="smpl">depth</a> (#PCDATA) &gt;

   &lt;!ELEMENT <a href="#ELEMENT_owner" class="smpl">owner</a> ANY &gt;

   &lt;!ELEMENT <a href="#ELEMENT_timeout" class="smpl">timeout</a> (#PCDATA) &gt;

   &lt;!ELEMENT <a href="#ELEMENT_locktoken" class="smpl">locktoken</a> (<a href="#ELEMENT_href" class="smpl">href</a>+) &gt;

   &lt;!ELEMENT <a href="#ELEMENT_href" class="smpl">href</a> (#PCDATA) &gt;

   &lt;!ELEMENT <a href="#ELEMENT_link" class="smpl">link</a> (<a href="#ELEMENT_src" class="smpl">src</a>+, <a href="#ELEMENT_dst" class="smpl">dst</a>+) &gt;
   &lt;!ELEMENT <a href="#ELEMENT_dst" class="smpl">dst</a> (#PCDATA) &gt;
   &lt;!ELEMENT <a href="#ELEMENT_src" class="smpl">src</a> (#PCDATA) &gt;

   &lt;!ELEMENT <a href="#ELEMENT_multistatus" class="smpl">multistatus</a> (<a href="#ELEMENT_response" class="smpl">response</a>+, <a href="#ELEMENT_responsedescription" class="smpl">responsedescription</a>?) &gt;

   &lt;!ELEMENT <a href="#ELEMENT_response" class="smpl">response</a> (<a href="#ELEMENT_href" class="smpl">href</a>, ((<a href="#ELEMENT_href" class="smpl">href</a>*, <a href="#ELEMENT_status" class="smpl">status</a>)|(<a href="#ELEMENT_propstat" class="smpl">propstat</a>+)),
   <a href="#ELEMENT_responsedescription" class="smpl">responsedescription</a>?) &gt;
   &lt;!ELEMENT <a href="#ELEMENT_status" class="smpl">status</a> (#PCDATA) &gt;
   &lt;!ELEMENT <a href="#ELEMENT_propstat" class="smpl">propstat</a> (<a href="#ELEMENT_prop" class="smpl">prop</a>, <a href="#ELEMENT_status" class="smpl">status</a>, <a href="#ELEMENT_responsedescription" class="smpl">responsedescription</a>?) &gt;
   &lt;!ELEMENT <a href="#ELEMENT_responsedescription" class="smpl">responsedescription</a> (#PCDATA) &gt;

   &lt;!ELEMENT <a href="#ELEMENT_prop" class="smpl">prop</a> ANY &gt;
   
   &lt;!ELEMENT <a href="#ELEMENT_propertybehaviour" class="smpl">propertybehavior</a> (<a href="#ELEMENT_omit" class="smpl">omit</a> | <a href="#ELEMENT_keepalive" class="smpl">keepalive</a>) &gt;
   &lt;!ELEMENT <a href="#ELEMENT_omit" class="smpl">omit</a> EMPTY &gt;

   &lt;!ELEMENT <a href="#ELEMENT_keepalive" class="smpl">keepalive</a> (#PCDATA | <a href="#ELEMENT_href" class="smpl">href</a>+) &gt;

   &lt;!ELEMENT <a href="#ELEMENT_propertyupdate" class="smpl">propertyupdate</a> (<a href="#ELEMENT_remove" class="smpl">remove</a> | <a href="#ELEMENT_set" class="smpl">set</a>)+ &gt;
   &lt;!ELEMENT <a href="#ELEMENT_remove" class="smpl">remove</a> (<a href="#ELEMENT_prop" class="smpl">prop</a>) &gt;
   &lt;!ELEMENT <a href="#ELEMENT_set" class="smpl">set</a> (<a href="#ELEMENT_prop" class="smpl">prop</a>) &gt;

   &lt;!ELEMENT <a href="#ELEMENT_propfind" class="smpl">propfind</a> (<a href="#ELEMENT_allprop" class="smpl">allprop</a> | <a href="#ELEMENT_propname" class="smpl">propname</a> | <a href="#ELEMENT_prop" class="smpl">prop</a>) &gt;
   &lt;!ELEMENT <a href="#ELEMENT_allprop" class="smpl">allprop</a> EMPTY &gt;
   &lt;!ELEMENT <a href="#ELEMENT_propname" class="smpl">propname</a> EMPTY &gt;

   &lt;!ELEMENT <a href="#ELEMENT_collection" class="smpl">collection</a> EMPTY &gt;

   &lt;!--=========== Property Elements from <a href="#dav.properties" title="DAV Properties">Section&nbsp;13</a> ===============--&gt;
   &lt;!ELEMENT <a href="#PROPERTY_creationdate" class="smpl">creationdate</a> (#PCDATA) &gt;
   &lt;!ELEMENT <a href="#PROPERTY_displayname" class="smpl">displayname</a> (#PCDATA) &gt;
   &lt;!ELEMENT <a href="#PROPERTY_getcontentlanguage" class="smpl">getcontentlanguage</a> (#PCDATA) &gt;
   &lt;!ELEMENT <a href="#PROPERTY_getcontentlength" class="smpl">getcontentlength</a> (#PCDATA) &gt;
   &lt;!ELEMENT <a href="#PROPERTY_getcontenttype" class="smpl">getcontenttype</a> (#PCDATA) &gt;
   &lt;!ELEMENT <a href="#PROPERTY_getetag" class="smpl">getetag</a> (#PCDATA) &gt;
   &lt;!ELEMENT <a href="#PROPERTY_getlastmodified" class="smpl">getlastmodified</a> (#PCDATA) &gt;
   &lt;!ELEMENT <a href="#PROPERTY_lockdiscovery" class="smpl">lockdiscovery</a> (<a href="#ELEMENT_activelock" class="smpl">activelock</a>)* &gt;
   &lt;!ELEMENT <a href="#PROPERTY_resourcetype" class="smpl">resourcetype</a> ANY &gt;
   &lt;!ELEMENT <a href="#PROPERTY_source" class="smpl">source</a> (<a href="#ELEMENT_link" class="smpl">link</a>)* &gt;
   &lt;!ELEMENT <a href="#PROPERTY_supportedlock" class="smpl">supportedlock</a> (<a href="#ELEMENT_lockentry" class="smpl">lockentry</a>)* &gt;
   ]&gt;
</pre></div></section><section id="iso.8601.date.and.time.profile"><h3 id="rfc.section.23.2"><a href="#rfc.section.23.2">23.2</a>&nbsp;<a href="#iso.8601.date.and.time.profile">Appendix 2 - ISO 8601 Date and Time Profile</a></h3><div id="rfc.section.23.2.p.1"><p>The creationdate property specifies the use of the ISO 8601 date format <a href="#ISO-8601" id="rfc.xref.ISO-8601.1"><cite title="ISO 8601, Data elements and interchange formats-Information interchange--Representation of dates and times">[ISO-8601]</cite></a>.
 This section defines a profile of the ISO 8601 date format for use with
 this specification. This profile is quoted from an Internet-Draft by 
Chris Newman, and is mentioned here to properly attribute his work.<a class="self" href="#rfc.section.23.2.p.1">¶</a></p></div><div id="rfc.figure.u.93"><pre class="inline">   date-time       = full-date "T" full-time

   full-date       = date-fullyear "-" date-month "-" date-mday
   full-time       = partial-time time-offset

   date-fullyear   = 4DIGIT
   date-month      = 2DIGIT  ; 01-12
   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
   month/year
   time-hour       = 2DIGIT  ; 00-23
   time-minute     = 2DIGIT  ; 00-59
   time-second     = 2DIGIT  ; 00-59, 00-60 based on leap second rules
   time-secfrac    = "." 1*DIGIT
   time-numoffset  = ("+" / "-") time-hour ":" time-minute
   time-offset     = "Z" / time-numoffset

   partial-time    = time-hour ":" time-minute ":" time-second
                    [time-secfrac]
</pre></div><div id="rfc.section.23.2.p.2"><p>Numeric offsets are 
calculated as local time minus UTC (Coordinated Universal Time). So the 
equivalent time in UTC can be determined by subtracting the offset from 
the local time. For example, 18:50:00-04:00 is the same time as 
22:58:00Z.<a class="self" href="#rfc.section.23.2.p.2">¶</a></p></div><div id="rfc.section.23.2.p.3"><p>If
 the time in UTC is known, but the offset to local time is unknown, this
 can be represented with an offset of "-00:00". This differs from an 
offset of "Z" which implies that UTC is the preferred reference point 
for the specified time.<a class="self" href="#rfc.section.23.2.p.3">¶</a></p></div></section><section id="n-appendix-3---notes-on-processing-xml-elements"><h3 id="rfc.section.23.3"><a href="#rfc.section.23.3">23.3</a>&nbsp;<a href="#n-appendix-3---notes-on-processing-xml-elements">Appendix 3 - Notes on Processing XML Elements</a></h3><section id="n-notes-on-empty-xml-elements"><h4 id="rfc.section.23.3.1"><a href="#rfc.section.23.3.1">23.3.1</a>&nbsp;<a href="#n-notes-on-empty-xml-elements">Notes on Empty XML Elements</a></h4><div id="rfc.section.23.3.1.p.1"><p>XML
 supports two mechanisms for indicating that an XML element does not 
have any content. The first is to declare an XML element of the form 
&lt;A&gt;&lt;/A&gt;. The second is to declare an XML element of the form
 &lt;A/&gt;. The two XML elements are semantically identical.<a class="self" href="#rfc.section.23.3.1.p.1">¶</a></p></div><div id="rfc.section.23.3.1.p.2"><p>It
 is a violation of the XML specification to use the &lt;A&gt;&lt;/A&gt; 
form if the associated DTD declares the element to be EMPTY (e.g., 
&lt;!ELEMENT A EMPTY&gt;). If such a statement is included, then the 
empty element format, &lt;A/&gt; must be used. If the element is not 
declared to be EMPTY, then either form &lt;A&gt;&lt;/A&gt; or &lt;A/&gt;
 may be used for empty elements.<a class="self" href="#rfc.section.23.3.1.p.2">¶</a></p></div></section><section id="n-notes-on-illegal-xml-processing"><h4 id="rfc.section.23.3.2"><a href="#rfc.section.23.3.2">23.3.2</a>&nbsp;<a href="#n-notes-on-illegal-xml-processing">Notes on Illegal XML Processing</a></h4><div id="rfc.section.23.3.2.p.1"><p>XML
 is a flexible data format that makes it easy to submit data that 
appears legal but in fact is not. The philosophy of "Be flexible in what
 you accept and strict in what you send" still applies, but it must not 
be applied inappropriately. XML is extremely flexible in dealing with 
issues of white space, element ordering, inserting new elements, etc. 
This flexibility does not require extension, especially not in the area 
of the meaning of elements.<a class="self" href="#rfc.section.23.3.2.p.1">¶</a></p></div><div id="rfc.section.23.3.2.p.2"><p>There
 is no kindness in accepting illegal combinations of XML elements. At 
best it will cause an unwanted result and at worst it can cause real 
damage.<a class="self" href="#rfc.section.23.3.2.p.2">¶</a></p></div><section id="n-example---xml-syntax-error"><h5 id="rfc.section.23.3.2.1"><a href="#rfc.section.23.3.2.1">23.3.2.1</a>&nbsp;<a href="#n-example---xml-syntax-error">Example - XML Syntax Error</a></h5><div id="rfc.section.23.3.2.1.p.1"><p>The following request body for a PROPFIND method is illegal.<a class="self" href="#rfc.section.23.3.2.1.p.1">¶</a></p></div><div id="rfc.figure.u.94"><pre class="text">   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:propfind xmlns:D="DAV:"&gt;
     &lt;D:allprop/&gt;
     &lt;D:propname/&gt;
   &lt;/D:propfind&gt;
</pre></div><div id="rfc.section.23.3.2.1.p.2"><p>The definition of the 
propfind element only allows for the allprop or the propname element, 
not both. Thus the above is an error and must be responded to with a 400
 (Bad Request).<a class="self" href="#rfc.section.23.3.2.1.p.2">¶</a></p></div><div id="rfc.section.23.3.2.1.p.3"><p>Imagine,
 however, that a server wanted to be "kind" and decided to pick the 
allprop element as the true element and respond to it. A client running 
over a bandwidth limited line who intended to execute a propname would 
be in for a big surprise if the server treated the command as an 
allprop.<a class="self" href="#rfc.section.23.3.2.1.p.3">¶</a></p></div><div id="rfc.section.23.3.2.1.p.4"><p>Additionally,
 if a server were lenient and decided to reply to this request, the 
results would vary randomly from server to server, with some servers 
executing the allprop directive, and others executing the propname 
directive. This reduces interoperability rather than increasing it.<a class="self" href="#rfc.section.23.3.2.1.p.4">¶</a></p></div></section><section id="n-example---unknown-xml-element"><h5 id="rfc.section.23.3.2.2"><a href="#rfc.section.23.3.2.2">23.3.2.2</a>&nbsp;<a href="#n-example---unknown-xml-element">Example - Unknown XML Element</a></h5><div id="rfc.section.23.3.2.2.p.1"><p>The
 previous example was illegal because it contained two elements that 
were explicitly banned from appearing together in the propfind element. 
However, XML is an extensible language, so one can imagine new elements 
being defined for use with propfind. Below is the request body of a 
PROPFIND and, like the previous example, must be rejected with a 400 
(Bad Request) by a server that does not understand the expired-props 
element.<a class="self" href="#rfc.section.23.3.2.2.p.1">¶</a></p></div><div id="rfc.figure.u.95"><pre class="text">   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:propfind xmlns:D="DAV:"
   xmlns:E="http://www.foo.bar/standards/props/"&gt;
     &lt;E:expired-props/&gt;
   &lt;/D:propfind&gt;
</pre></div><div id="rfc.section.23.3.2.2.p.2"><p>To understand why a 
400 (Bad Request) is returned let us look at the request body as the 
server unfamiliar with expired-props sees it.<a class="self" href="#rfc.section.23.3.2.2.p.2">¶</a></p></div><div id="rfc.figure.u.96"><pre class="text">   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:propfind xmlns:D="DAV:"
               xmlns:E="http://www.foo.bar/standards/props/"&gt;
   &lt;/D:propfind&gt;
</pre></div><div id="rfc.section.23.3.2.2.p.3"><p>As the server does not understand the expired-props element, according to the WebDAV-specific XML processing rules specified in <a href="#instructions.for.processing.xml.in.dav" title="Instructions for Processing XML in DAV">Section&nbsp;14</a>, it must ignore it. Thus the server sees an empty propfind, which by the definition of the propfind element is illegal.<a class="self" href="#rfc.section.23.3.2.2.p.3">¶</a></p></div><div id="rfc.section.23.3.2.2.p.4" class="avoidbreakafter"><p>Please
 note that had the extension been additive it would not necessarily have
 resulted in a 400 (Bad Request). For example, imagine the following 
request body for a PROPFIND:<a class="self" href="#rfc.section.23.3.2.2.p.4">¶</a></p></div><div id="rfc.figure.u.97"><pre class="text">   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
   &lt;D:propfind xmlns:D="DAV:"
               xmlns:E="http://www.foo.bar/standards/props/"&gt;
     &lt;D:propname/&gt;
     &lt;E:leave-out&gt;*boss*&lt;/E:leave-out&gt;
   &lt;/D:propfind&gt;
</pre></div><div id="rfc.section.23.3.2.2.p.5"><p>The previous example 
contains the fictitious element leave-out. Its purpose is to prevent the
 return of any property whose name matches the submitted pattern. If the
 previous example were submitted to a server unfamiliar with leave-out, 
the only result would be that the leave-out element would be ignored and
 a propname would be executed.<a class="self" href="#rfc.section.23.3.2.2.p.5">¶</a></p></div></section></section></section><section id="xml.namespaces.for.webdav"><h3 id="rfc.section.23.4"><a href="#rfc.section.23.4">23.4</a>&nbsp;<a href="#xml.namespaces.for.webdav">Appendix 4 -- XML Namespaces for WebDAV</a></h3><section id="n-introduction_2"><h4 id="rfc.section.23.4.1"><a href="#rfc.section.23.4.1">23.4.1</a>&nbsp;<a href="#n-introduction_2">Introduction</a></h4><div id="rfc.section.23.4.1.p.1"><p>All DAV compliant systems <em class="bcp14">MUST</em> support the XML namespace extensions as specified in <a href="#REC-XML-NAMES" id="rfc.xref.REC-XML-NAMES.1"><cite title="Namespaces in XML">[REC-XML-NAMES]</cite></a>.<a class="self" href="#rfc.section.23.4.1.p.1">¶</a></p></div></section><section id="n-meaning-of-qualified-names"><h4 id="rfc.section.23.4.2"><a href="#rfc.section.23.4.2">23.4.2</a>&nbsp;<a href="#n-meaning-of-qualified-names">Meaning of Qualified Names</a></h4><div id="rfc.section.23.4.2.p.1"><p>[Note to the reader: This section does not appear in <a href="#REC-XML-NAMES" id="rfc.xref.REC-XML-NAMES.2"><cite title="Namespaces in XML">[REC-XML-NAMES]</cite></a>, but is necessary to avoid ambiguity for WebDAV XML processors.]<a class="self" href="#rfc.section.23.4.2.p.1">¶</a></p></div><div id="rfc.section.23.4.2.p.2"><p>WebDAV compliant XML processors <em class="bcp14">MUST</em> interpret a qualified name as a URI constructed by appending the LocalPart to the namespace name URI.<a class="self" href="#rfc.section.23.4.2.p.2">¶</a></p></div><div id="rfc.figure.u.98"><p>Example</p><pre class="text">   &lt;del:glider xmlns:del="http://www.del.jensen.org/"&gt;
     &lt;del:glidername&gt;
          Johnny Updraft
     &lt;/del:glidername&gt;
     &lt;del:glideraccidents/&gt;
   &lt;/del:glider&gt;
</pre></div><div id="rfc.section.23.4.2.p.3"><p>In this example, the qualified element name "del:glider" is interpreted as the URL "http://www.del.jensen.org/glider".<a class="self" href="#rfc.section.23.4.2.p.3">¶</a></p></div><div id="rfc.figure.u.99"><pre class="text">   &lt;bar:glider xmlns:del="http://www.del.jensen.org/"&gt;
     &lt;bar:glidername&gt;
          Johnny Updraft
     &lt;/bar:glidername&gt;
     &lt;bar:glideraccidents/&gt;
   &lt;/bar:glider&gt;
</pre></div><div id="rfc.section.23.4.2.p.4"><p>Even though this example
 is syntactically different from the previous example, it is 
semantically identical. Each instance of the namespace name "bar" is 
replaced with "http://www.del.jensen.org/" and then appended to the 
local name for each element tag. The resulting tag names in this example
 are exactly the same as for the previous example.<a class="self" href="#rfc.section.23.4.2.p.4">¶</a></p></div><div id="rfc.figure.u.100"><pre class="text">   &lt;foo:r xmlns:foo="http://www.del.jensen.org/glide"&gt;
     &lt;foo:rname&gt;
          Johnny Updraft
     &lt;/foo:rname&gt;
     &lt;foo:raccidents/&gt;
   &lt;/foo:r&gt;
</pre></div><div id="rfc.section.23.4.2.p.5"><p>This example is 
semantically identical to the two previous ones. Each instance of the 
namespace name "foo" is replaced with "http://www.del.jensen.org/glide" 
which is then appended to the local name for each element tag, the 
resulting tag names are identical to those in the previous examples.<a class="self" href="#rfc.section.23.4.2.p.5">¶</a></p></div></section></section></section><section id="rfc.index"><h2><a href="#rfc.index">Index</a></h2><p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.5">5</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.K">K</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.W">W</a> </p><div class="print2col"><ul class="ind"><li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul><li>102 Processing (status code)&nbsp;&nbsp;<a href="#rfc.section.9.7">9.7</a>, <a href="#rfc.section.10.1"><b>10.1</b></a></li></ul></li><li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul><li>207 Multi-Status (status code)&nbsp;&nbsp;<a href="#rfc.section.10.2"><b>10.2</b></a>, <a href="#rfc.section.11">11</a></li></ul></li><li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul><li>422 Unprocessable Entity (status code)&nbsp;&nbsp;<a href="#rfc.section.10.3"><b>10.3</b></a></li><li>423 Locked (status code)&nbsp;&nbsp;<a href="#rfc.section.10.4"><b>10.4</b></a></li><li>424 Failed Dependency (status code)&nbsp;&nbsp;<a href="#rfc.section.10.5"><b>10.5</b></a></li></ul></li><li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul><li>507 Insufficient Storage (status code)&nbsp;&nbsp;<a href="#rfc.section.10.6"><b>10.6</b></a></li></ul></li><li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul><li>activelock&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.1">12.1</a></li></ul></li><li>allprop&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.14.1">12.14.1</a></li></ul></li></ul></li><li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul><li>Collection&nbsp;&nbsp;<a href="#rfc.iref.c.1">3</a></li><li>COPY method&nbsp;&nbsp;<a href="#rfc.section.8.8"><b>8.8</b></a></li></ul></li><li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul><li>DAV header&nbsp;&nbsp;<a href="#rfc.section.9.1"><b>9.1</b></a><ul><li>compliance class '1'&nbsp;&nbsp;<a href="#rfc.section.15.1"><b>15.1</b></a></li><li>compliance class '2'&nbsp;&nbsp;<a href="#rfc.section.15.2"><b>15.2</b></a></li></ul></li><li>DAV:collection resource type&nbsp;&nbsp;<a href="#rfc.section.12.2"><b>12.2</b></a></li><li>DAV:creationdate property&nbsp;&nbsp;<a href="#rfc.section.13.1"><b>13.1</b></a></li><li>DAV:displayname property&nbsp;&nbsp;<a href="#rfc.section.13.2"><b>13.2</b></a></li><li>DAV:getcontentlanguage property&nbsp;&nbsp;<a href="#rfc.section.13.3"><b>13.3</b></a></li><li>DAV:getcontentlength property&nbsp;&nbsp;<a href="#rfc.section.13.4"><b>13.4</b></a></li><li>DAV:getcontenttype property&nbsp;&nbsp;<a href="#rfc.section.13.5"><b>13.5</b></a></li><li>DAV:getetag property&nbsp;&nbsp;<a href="#rfc.section.13.6"><b>13.6</b></a></li><li>DAV:getlastmodified property&nbsp;&nbsp;<a href="#rfc.section.13.7"><b>13.7</b></a></li><li>DAV:lockdiscovery property&nbsp;&nbsp;<a href="#rfc.section.13.8"><b>13.8</b></a></li><li>DAV:resourcetype property&nbsp;&nbsp;<a href="#rfc.section.13.9"><b>13.9</b></a></li><li>DAV:source property&nbsp;&nbsp;<a href="#rfc.section.13.10"><b>13.10</b></a></li><li>DAV:supportedlock property&nbsp;&nbsp;<a href="#rfc.section.13.11"><b>13.11</b></a></li><li>Dead Property&nbsp;&nbsp;<a href="#rfc.iref.d.1">3</a></li><li>DELETE method&nbsp;&nbsp;<a href="#rfc.section.8.6"><b>8.6</b></a></li><li>depth&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.1.1">12.1.1</a></li></ul></li><li>Depth header&nbsp;&nbsp;<a href="#rfc.section.9.2"><b>9.2</b></a></li><li>Destination header&nbsp;&nbsp;<a href="#rfc.section.9.3"><b>9.3</b></a></li><li>dst&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.4.1">12.4.1</a></li></ul></li></ul></li><li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul><li>exclusive&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.7.1">12.7.1</a></li></ul></li></ul></li><li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul><li>Headers&nbsp;&nbsp;<ul><li>DAV&nbsp;&nbsp;<a href="#rfc.section.9.1"><b>9.1</b></a></li><li>Depth&nbsp;&nbsp;<a href="#rfc.section.9.2"><b>9.2</b></a></li><li>Destination&nbsp;&nbsp;<a href="#rfc.section.9.3"><b>9.3</b></a></li><li>If&nbsp;&nbsp;<a href="#rfc.section.9.4"><b>9.4</b></a></li><li>Lock-Token&nbsp;&nbsp;<a href="#rfc.section.9.5"><b>9.5</b></a></li><li>Overwrite&nbsp;&nbsp;<a href="#rfc.section.9.6"><b>9.6</b></a></li><li>Status-URI&nbsp;&nbsp;<a href="#rfc.section.9.7"><b>9.7</b></a></li><li>Timeout&nbsp;&nbsp;<a href="#rfc.section.9.8"><b>9.8</b></a></li></ul></li><li>href&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.3">12.3</a></li></ul></li></ul></li><li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul><li>If header&nbsp;&nbsp;<a href="#rfc.section.9.4"><b>9.4</b></a></li><li>Internal Member URI&nbsp;&nbsp;<a href="#rfc.iref.i.1">3</a></li><li><em>ISO-11578</em>&nbsp;&nbsp;<a href="#rfc.xref.ISO-11578.1">6.4</a>, <a href="#rfc.xref.ISO-11578.2">6.4</a>, <a href="#rfc.xref.ISO-11578.3">6.4.1</a>, <a href="#rfc.xref.ISO-11578.4">17.8</a>, <a href="#ISO-11578"><b>21.1</b></a></li><li><em>ISO-639</em>&nbsp;&nbsp;<a href="#rfc.xref.ISO-639.1">16</a>, <a href="#ISO-639"><b>21.1</b></a></li><li><em>ISO-8601</em>&nbsp;&nbsp;<a href="#ISO-8601"><b>21.1</b></a>, <a href="#rfc.xref.ISO-8601.1">23.2</a></li></ul></li><li><a id="rfc.index.K" href="#rfc.index.K"><b>K</b></a><ul><li>keepalive&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.12.1">12.12.1</a></li></ul></li></ul></li><li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul><li>link&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.4">12.4</a></li></ul></li><li>Live Property&nbsp;&nbsp;<a href="#rfc.iref.l.1">3</a></li><li>LOCK method&nbsp;&nbsp;<a href="#rfc.section.8.10"><b>8.10</b></a></li><li>Lock-Token header&nbsp;&nbsp;<a href="#rfc.section.9.5"><b>9.5</b></a></li><li>lockentry&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.5">12.5</a></li></ul></li><li>lockinfo&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.6">12.6</a></li></ul></li><li>lockscope&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.7">12.7</a></li></ul></li><li>locktoken&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.1.2">12.1.2</a></li></ul></li><li>locktype&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.8">12.8</a></li></ul></li></ul></li><li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul><li>Member URI&nbsp;&nbsp;<a href="#rfc.iref.m.1">3</a></li><li>Methods&nbsp;&nbsp;<ul><li>COPY&nbsp;&nbsp;<a href="#rfc.section.8.8"><b>8.8</b></a></li><li>DELETE&nbsp;&nbsp;<a href="#rfc.section.8.6"><b>8.6</b></a></li><li>LOCK&nbsp;&nbsp;<a href="#rfc.section.8.10"><b>8.10</b></a></li><li>MKCOL&nbsp;&nbsp;<a href="#rfc.section.8.3"><b>8.3</b></a></li><li>MOVE&nbsp;&nbsp;<a href="#rfc.section.8.9"><b>8.9</b></a></li><li>PROPFIND&nbsp;&nbsp;<a href="#rfc.section.8.1"><b>8.1</b></a></li><li>PROPPATCH&nbsp;&nbsp;<a href="#rfc.section.8.2"><b>8.2</b></a></li><li>PUT&nbsp;&nbsp;<a href="#rfc.section.8.7"><b>8.7</b></a></li><li>UNLOCK&nbsp;&nbsp;<a href="#rfc.section.8.11"><b>8.11</b></a></li></ul></li><li>MKCOL method&nbsp;&nbsp;<a href="#rfc.section.8.3"><b>8.3</b></a></li><li>MOVE method&nbsp;&nbsp;<a href="#rfc.section.8.9"><b>8.9</b></a></li><li>multistatus&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.9">12.9</a></li></ul></li></ul></li><li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul><li>Null Resource&nbsp;&nbsp;<a href="#rfc.iref.n.1">3</a></li></ul></li><li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul><li>omit&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.12.2">12.12.2</a></li></ul></li><li>Overwrite header&nbsp;&nbsp;<a href="#rfc.section.9.6"><b>9.6</b></a></li><li>owner&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.10">12.10</a></li></ul></li></ul></li><li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul><li>prop&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.11">12.11</a></li></ul></li><li>Properties&nbsp;&nbsp;<ul><li>DAV:creationdate&nbsp;&nbsp;<a href="#rfc.section.13.1"><b>13.1</b></a></li><li>DAV:displayname&nbsp;&nbsp;<a href="#rfc.section.13.2"><b>13.2</b></a></li><li>DAV:getcontentlanguage&nbsp;&nbsp;<a href="#rfc.section.13.3"><b>13.3</b></a></li><li>DAV:getcontentlength&nbsp;&nbsp;<a href="#rfc.section.13.4"><b>13.4</b></a></li><li>DAV:getcontenttype&nbsp;&nbsp;<a href="#rfc.section.13.5"><b>13.5</b></a></li><li>DAV:getetag&nbsp;&nbsp;<a href="#rfc.section.13.6"><b>13.6</b></a></li><li>DAV:getlastmodified&nbsp;&nbsp;<a href="#rfc.section.13.7"><b>13.7</b></a></li><li>DAV:lockdiscovery&nbsp;&nbsp;<a href="#rfc.section.13.8"><b>13.8</b></a></li><li>DAV:resourcetype&nbsp;&nbsp;<a href="#rfc.section.13.9"><b>13.9</b></a></li><li>DAV:source&nbsp;&nbsp;<a href="#rfc.section.13.10"><b>13.10</b></a></li><li>DAV:supportedlock&nbsp;&nbsp;<a href="#rfc.section.13.11"><b>13.11</b></a></li></ul></li><li>Property&nbsp;&nbsp;<a href="#rfc.iref.p.1">3</a></li><li>propertybehaviour&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.12">12.12</a></li></ul></li><li>propertyupdate&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.13">12.13</a></li></ul></li><li>propfind&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.14">12.14</a></li></ul></li><li>PROPFIND method&nbsp;&nbsp;<a href="#rfc.section.8.1"><b>8.1</b></a></li><li>propname&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.14.2">12.14.2</a></li></ul></li><li>PROPPATCH method&nbsp;&nbsp;<a href="#rfc.section.8.2"><b>8.2</b></a></li><li>propstat&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.9.1.1">12.9.1.1</a></li></ul></li><li>PUT method&nbsp;&nbsp;<a href="#rfc.section.8.7"><b>8.7</b></a></li></ul></li><li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul><li><em>REC-PICS</em>&nbsp;&nbsp;<a href="#rfc.xref.REC-PICS.1">4.2</a>, <a href="#REC-PICS"><b>21.2</b></a></li><li><em>REC-XML</em>&nbsp;&nbsp;<a href="#rfc.xref.REC-XML.1">1</a>, <a href="#rfc.xref.REC-XML.2">8</a>, <a href="#rfc.xref.REC-XML.3">12</a>, <a href="#rfc.xref.REC-XML.4">13</a>, <a href="#rfc.xref.REC-XML.5">17.7</a>, <a href="#rfc.xref.REC-XML.6">17.7</a>, <a href="#rfc.xref.REC-XML.7">17.7</a>, <a href="#rfc.xref.REC-XML.8">17.7</a>, <a href="#REC-XML"><b>21.1</b></a>, <a href="#rfc.xref.REC-XML.9">23.1</a><ul><li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.REC-XML.5">17.7</a></li></ul></li><li><em>REC-XML-NAMES</em>&nbsp;&nbsp;<a href="#REC-XML-NAMES"><b>21.1</b></a>, <a href="#rfc.xref.REC-XML-NAMES.1">23.4.1</a>, <a href="#rfc.xref.REC-XML-NAMES.2">23.4.2</a></li><li>remove&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.13.1">12.13.1</a></li></ul></li><li>Resource Types&nbsp;&nbsp;<ul><li>DAV:collection&nbsp;&nbsp;<a href="#rfc.section.12.2"><b>12.2</b></a></li></ul></li><li>response&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.9.1">12.9.1</a></li></ul></li><li>responsedescription&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.9.2">12.9.2</a></li></ul></li><li><em>RFC1766</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1766.1">16</a>, <a href="#RFC1766"><b>21.1</b></a></li><li><em>RFC1807</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1807.1">4.2</a>, <a href="#RFC1807"><b>21.2</b></a></li><li><em>RFC2026</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2026.1">19</a>, <a href="#rfc.xref.RFC2026.2">19</a>, <a href="#RFC2026"><b>21.2</b></a><ul><li><em>Section 10.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2026.2">19</a></li></ul></li><li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">2</a>, <a href="#rfc.xref.RFC2068.2">2</a>, <a href="#rfc.xref.RFC2068.3">2</a>, <a href="#rfc.xref.RFC2068.4">2</a>, <a href="#rfc.xref.RFC2068.5">5.1</a>, <a href="#rfc.xref.RFC2068.6">6.4</a>, <a href="#rfc.xref.RFC2068.7">6.4</a>, <a href="#rfc.xref.RFC2068.8">8.4</a>, <a href="#rfc.xref.RFC2068.9">8.7.2</a>, <a href="#rfc.xref.RFC2068.10">9.4</a>, <a href="#rfc.xref.RFC2068.11">9.4</a>, <a href="#rfc.xref.RFC2068.12">9.7</a>, <a href="#rfc.xref.RFC2068.13">9.7</a>, <a href="#rfc.xref.RFC2068.14">9.8</a>, <a href="#rfc.xref.RFC2068.15">9.8</a>, <a href="#rfc.xref.RFC2068.16">10</a>, <a href="#rfc.xref.RFC2068.17">12.3</a>, <a href="#rfc.xref.RFC2068.18">12.3</a>, <a href="#rfc.xref.RFC2068.19">12.9.1.2</a>, <a href="#rfc.xref.RFC2068.20">13.3</a>, <a href="#rfc.xref.RFC2068.21">13.3</a>, <a href="#rfc.xref.RFC2068.22">13.4</a>, <a href="#rfc.xref.RFC2068.23">13.4</a>, <a href="#rfc.xref.RFC2068.24">13.5</a>, <a href="#rfc.xref.RFC2068.25">13.5</a>, <a href="#rfc.xref.RFC2068.26">13.6</a>, <a href="#rfc.xref.RFC2068.27">13.6</a>, <a href="#rfc.xref.RFC2068.28">13.7</a>, <a href="#rfc.xref.RFC2068.29">13.7</a>, <a href="#rfc.xref.RFC2068.30">15</a>, <a href="#rfc.xref.RFC2068.31">17</a>, <a href="#RFC2068"><b>21.1</b></a><ul><li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">2</a></li><li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">2</a></li><li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.6">6.4</a>, <a href="#rfc.xref.RFC2068.17">12.3</a></li><li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.28">13.7</a></li><li><em>Section 3.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.24">13.5</a></li><li><em>Section 3.11</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.26">13.6</a></li><li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.14">9.8</a></li><li><em>Section 6.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.12">9.7</a></li><li><em>Section 14.13</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.20">13.3</a></li><li><em>Section 14.14</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.22">13.4</a></li><li><em>Section 14.25</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.10">9.4</a></li></ul></li><li><em>RFC2069</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2069.1">17.1</a>, <a href="#RFC2069"><b>21.1</b></a></li><li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">2</a>, <a href="#RFC2119"><b>21.1</b></a></li><li><em>RFC2141</em>&nbsp;&nbsp;<a href="#RFC2141"><b>21.1</b></a></li><li><em>RFC2277</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2277.1">16</a>, <a href="#RFC2277"><b>21.1</b></a></li><li><em>RFC2291</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2291.1">1</a>, <a href="#RFC2291"><b>21.2</b></a></li><li><em>RFC2376</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2376.1">16</a>, <a href="#rfc.xref.RFC2376.2">16</a>, <a href="#rfc.xref.RFC2376.3">17</a>, <a href="#rfc.xref.RFC2376.4">17.7</a>, <a href="#RFC2376"><b>21.2</b></a></li><li><em>RFC2396</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2396.1">3</a>, <a href="#rfc.xref.RFC2396.2">4.5</a>, <a href="#rfc.xref.RFC2396.3">5.1</a>, <a href="#rfc.xref.RFC2396.4">5.2</a>, <a href="#rfc.xref.RFC2396.5">5.2</a>, <a href="#rfc.xref.RFC2396.6">9.3</a>, <a href="#rfc.xref.RFC2396.7">9.4</a>, <a href="#RFC2396"><b>21.1</b></a><ul><li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2396.4">5.2</a></li></ul></li><li><em>RFC2413</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2413.1">4.2</a>, <a href="#RFC2413"><b>21.2</b></a></li></ul></li><li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul><li>set&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.13.2">12.13.2</a></li></ul></li><li>shared&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.7.2">12.7.2</a></li></ul></li><li>src&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.4.2">12.4.2</a></li></ul></li><li>status&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.9.1.2">12.9.1.2</a></li></ul></li><li>Status Codes&nbsp;&nbsp;<ul><li>102 Processing&nbsp;&nbsp;<a href="#rfc.section.9.7">9.7</a>, <a href="#rfc.section.10.1"><b>10.1</b></a></li><li>207 Multi-Status&nbsp;&nbsp;<a href="#rfc.section.10.2"><b>10.2</b></a>, <a href="#rfc.section.11">11</a></li><li>422 Unprocessable Entity&nbsp;&nbsp;<a href="#rfc.section.10.3"><b>10.3</b></a></li><li>423 Locked&nbsp;&nbsp;<a href="#rfc.section.10.4"><b>10.4</b></a></li><li>424 Failed Dependency&nbsp;&nbsp;<a href="#rfc.section.10.5"><b>10.5</b></a></li><li>507 Insufficient Storage&nbsp;&nbsp;<a href="#rfc.section.10.6"><b>10.6</b></a></li></ul></li><li>Status-URI header&nbsp;&nbsp;<a href="#rfc.section.9.7"><b>9.7</b></a></li></ul></li><li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul><li>timeout&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.1.3">12.1.3</a></li></ul></li><li>Timeout header&nbsp;&nbsp;<a href="#rfc.section.9.8"><b>9.8</b></a></li></ul></li><li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul><li>UNLOCK method&nbsp;&nbsp;<a href="#rfc.section.8.11"><b>8.11</b></a></li><li>URI&nbsp;&nbsp;<a href="#rfc.iref.u.1">3</a></li><li>URL&nbsp;&nbsp;<a href="#rfc.iref.u.2">3</a></li><li><em>USMARC</em>&nbsp;&nbsp;<a href="#rfc.xref.USMARC.1">4.2</a>, <a href="#USMARC"><b>21.2</b></a></li><li><em>UTF-8</em>&nbsp;&nbsp;<a href="#rfc.xref.UTF-8.1">16</a>, <a href="#UTF-8"><b>21.1</b></a></li></ul></li><li><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul><li><em>WF</em>&nbsp;&nbsp;<a href="#rfc.xref.WF.1">4.2</a>, <a href="#rfc.xref.WF.2">4.2</a>, <a href="#WF"><b>21.2</b></a></li><li>write&nbsp;&nbsp;<ul><li>XML element&nbsp;&nbsp;<a href="#rfc.section.12.8.1">12.8.1</a></li></ul></li></ul></li></ul></div></section><section id="rfc.copyright"><h2><a href="#rfc.copyright">Full Copyright Statement</a></h2><p>Copyright © The Internet Society (1999). All Rights Reserved.</p><p>This
 document and translations of it may be copied and furnished to others, 
and derivative works that comment on or otherwise explain it or assist 
in its implementation may be prepared, copied, published and 
distributed, in whole or in part, without restriction of any kind, 
provided that the above copyright notice and this paragraph are included
 on all such copies and derivative works. However, this document itself 
may not be modified in any way, such as by removing the copyright notice
 or references to the Internet Society or other Internet organizations, 
except as needed for the purpose of developing Internet standards in 
which case the procedures for copyrights defined in the Internet 
Standards process must be followed, or as required to translate it into 
languages other than English.</p><p>The limited permissions granted 
above are perpetual and will not be revoked by the Internet Society or 
its successors or assigns.</p><p>This document and the information 
contained herein is provided on an “AS IS” basis and THE INTERNET 
SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 
PARTICULAR PURPOSE.</p></section><section id="rfc.ipr"><h2><a href="#rfc.ipr">Intellectual Property</a></h2><p>The
 IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to pertain 
to the implementation or use of the technology described in this 
document or the extent to which any license under such rights might or 
might not be available; neither does it represent that it has made any 
effort to identify any such rights. Information on the IETF's procedures
 with respect to rights in standards-track and standards-related 
documentation can be found in BCP-11. Copies of claims of rights made 
available for publication and any assurances of licenses to be made 
available, or the result of an attempt made to obtain a general license 
or permission for the use of such proprietary rights by implementors or 
users of this specification can be obtained from the IETF Secretariat.</p><p>The
 IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary rights 
which may cover technology that may be required to practice this 
standard. Please address the information to the IETF Executive Director.</p></section><section id="n-acknowledgment"><h2><a href="#n-acknowledgment">Acknowledgment</a></h2><p>Funding for the RFC Editor function is currently provided by the Internet Society.</p></section>
</body></html>